ISO/IEC 25791-1:2026

• Abstract:

  This document specifies the method for an application to: obtain OAuth tokens in a moderately secure manner for access to protected data; use OpenID Connect (OIDC) to identify the customer (user); and use tokens to access REST APIs in a moderately secure manner.

• Status: Published
• Publication Date: 03-Sep-2026
• ICS: 35.030 - IT Security
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 6060 - International Standard published
• Start Date: 04-Sep-2026
• Due Date: 18-Feb-2027
• Completion Date: 04-Sep-2026

ISO/IEC 25791-1:2026 is an International Standard published by ISO that defines the OpenID Connect FAPI Security Profile 1.0, Part 1: Baseline. It specifies how an application obtains OAuth tokens in a moderately secure manner, uses OpenID Connect (OIDC) to identify the customer (user), and uses tokens to access REST APIs in a moderately secure manner. It is intended for implementations that already use OAuth and OIDC and need a higher baseline of security.

What does ISO/IEC 25791-1:2026 specify?

ISO/IEC 25791-1:2026 specifies a baseline security profile for OAuth 2.0 and OIDC-based API access. It tells implementers how to obtain tokens, identify the user, and protect API access for cases with moderate inherent risk.

The document is organized into clauses on scope, normative references, terms and definitions, symbols and abbreviated terms, baseline security profile, accessing protected resources, security considerations, and privacy considerations. It also includes an informative acknowledgement annex.

What are the key requirements of ISO/IEC 25791-1:2026?

ISO/IEC 25791-1:2026 sets out requirements for the authorization server, clients, and protected resources, with added guidance for transport security and deployment choices. In practice, the standard focuses on safe token issuance, strict redirect handling, and controlled access to REST APIs.

Authorization server

The authorization server has to support confidential clients and should support public clients. For confidential clients, it has to use one of the approved client authentication methods: mutual TLS, client_secret_jwt, or private_key_jwt.

The server must require PKCE with S256, pre-registered redirect URIs, and an exact redirect_uri match. It must also require user authentication at an appropriate assurance level and explicit user approval for new scopes. These rules matter because they reduce code interception, redirect abuse, and unauthorized consent.

The server must reject reused authorization codes and issue token responses that follow OAuth 2.0 rules. It also has to return granted scopes when the authorization request passed in the front channel without integrity protection, so the client can detect scope tampering.

Client behavior

A public client has to support PKCE with S256, use a distinct redirect URI per authorization server, compare the redirect URI stored in the user-agent session with the one used in the response, and implement effective CSRF protection. If the client wants a persistent user identifier, it must request openid and include nonce; otherwise it must use state.

A confidential client has the public-client requirements and also has to support mutual TLS, client_secret_jwt, or private_key_jwt. It must use permitted key lengths, avoid deprecated algorithms, and verify that a symmetric client secret has at least 128 bits. In practice, this means the client must protect its own authentication as carefully as it protects user access.

Protected resources

The resource server must accept access tokens in the HTTP header and must not accept them in query parameters. It has to verify that the token is valid, unexpired, not revoked, and authorized for the requested resource.

For FAPI endpoints, the resource server must use GET, send JSON with UTF-8 when applicable, include the HTTP Date header, and echo or generate x-fapi-interaction-id values for traceability. It must log that interaction ID, which helps correlate client and server records during troubleshooting and audit work.

Security and deployment

All interactions have to use TLS over HTTPS, with TLS 1.2 or later and server certificate verification per RFC 6125. The document also calls out DNSSEC, HSTS, and CAA as useful protections against network and certificate attacks.

For native apps, the standard allows only claimed HTTPS scheme URI redirection for registered redirect URIs. It also requires clients to use metadata from the authorization server’s well-known metadata endpoint, which helps prevent spoofed discovery data.

What terms does ISO/IEC 25791-1:2026 define?

Clause 3 says the terms defined in RFC 6749, RFC 6750, RFC 7636, and OIDC apply. Clause 4 then lists the document’s abbreviations.

• API - application programming interface; the protected interface being accessed.
• FAPI - the Financial-grade API security profile family named by the standard.
• OIDC - OpenID Connect; the identity layer used to identify the customer.
• RP - relying party; the client side that requests identity and tokens.
• JARM - JWT Secured Authorization Response Mode; a way to protect authorization responses.
• TLS - Transport Layer Security; the encrypted channel required for all interactions.
• DNSSEC - Domain Name System Security Extensions; used to strengthen DNS trust.
• CSRF - cross site request forgery; a client-side attack the profile requires protection against.

Who uses ISO/IEC 25791-1:2026?

ISO/IEC 25791-1:2026 is used by authorization server operators, API platform teams, identity architects, and client developers who already work with OAuth 2.0 and OIDC. It is especially relevant to organizations that want stronger protection than basic OAuth, including financial institutions and other APIs that handle sensitive data.

The introduction says the main audience is parties that already have a certified OIDC implementation and want a higher level of security. Quality and certification teams also use it to check whether implementations follow the baseline profile.

Which standards are used with ISO/IEC 25791-1:2026?

• RFC 6749 - provides the OAuth 2.0 authorization framework that the profile builds on.
• RFC 7636 - defines PKCE, which the profile requires with S256.
• RFC 8705 - defines mutual-TLS client authentication and certificate-bound access tokens.
• RFC 6125 - defines TLS server certificate identity checking.
• BCP195 - gives recommendations for secure use of TLS and DTLS.
• OIDC - OpenID Connect Core 1.0 with errata set 2, used for user authentication and ID Tokens.
• OIDD - OpenID Connect Discovery 1.0 with errata set 2, used for metadata discovery.
• RFC 7231 - supplies HTTP semantics and the Date header rules used by the resource server.
• BCP212 - gives the OAuth 2.0 recommendations for native apps.
• RFC 4122 - defines UUIDs, used for x-fapi-interaction-id.
• Part 2: Advanced - the companion profile for higher security needs.

What does the ISO/IEC 25791-1:2026 document contain?

ISO/IEC 25791-1:2026 contains baseline security provisions for authorization servers, public clients, confidential clients, protected resources, and client-to-resource interactions. It also includes sections on TLS and DNSSEC, message source authentication failure, message integrity protection failure, message containment failure, native apps, implementation completeness, discovery and multiple brands, and privacy considerations.

The document uses clause 5 for the baseline profile and clause 6 for access to protected resources. Clause 7 gives security considerations, including browser, logging, and token-lifetime risks, while clause 8 summarizes privacy issues and mitigation approaches. Annex A is informative and lists the acknowledgement of contributors.

International
Standard
ISO/IEC 25791-1
First edition
Information technology — OpenID
2026-09
Connect FAPI Security Profile 1.0 —
Part 1:
Baseline
Technologies de l'information — Profil de sécurité 1.0 basé sur le
protocole OpenID Connect conçu pour les API finanières, FAPI —
Partie 1: Niveau de référence
Reference number
© ISO/IEC 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
Contents
Foreword . iv
Introduction . v
Notational conventions . vi
1. Scope . 1
2. Normative references . 1
3. Terms and definitions . 2
4. Symbols and abbreviated terms . 2
5. Baseline security profile . 2
5.1 Introduction . 2
5.2 Baseline security provisions . 3
5.2.1 Introduction . 3
5.2.2 Authorization server . 3
5.2.3 Public client . 5
5.2.4 Confidential client. 5
6. Accessing Protected Resources . 6
6.1 Introduction . 6
6.2 Baseline access provisions . 6
6.2.1 Protected resources provisions . 6
6.2.2 Client provisions . 7
7. Security considerations . 7
7.1 TLS and DNSSEC considerations . 7
7.2 Message source authentication failure . 7
7.3 Message integrity protection failure . 8
7.4 Message containment failure . 8
7.4.1 Authorization request and response . 8
7.4.2 Token request and response . 8
7.4.3 Resource request and response . 8
7.5 Native Apps . 8
7.6 Incomplete or incorrect implementations of the specifications . 9
7.7 Discovery & Multiple Brands . 9
8. Privacy considerations . 9
Annex A (Informative) Acknowledgement . 11
Notices . 12
Bibliography . 13

© ISO/IEC 2026 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members
of ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
document should be noted (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the use of
(a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not received
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent database
available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held responsible for
identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by the OpenID Foundation (OIDF) (as FAPI Security Profile 1.0 - Part 1: Baseline)
and drafted in accordance with its editorial rules. It was adopted, under the JTC 1 PAS procedure, by Joint
Technical Committee ISO/IEC JTC 1, Information technology.
A list of all parts in the ISO/IEC 25791 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
© ISO/IEC 2026 – All rights reserved
iv
Introduction
FAPI is a highly secured OAuth profile that aims to provide specific implementation guidelines for security
and interoperability. The FAPI security profile can be applied to APIs in any market area that requires a higher
level of security than provided by standard OAuth or OpenID Connect. Among other security enhancements,
this specification provides a secure alternative to screen scraping. Screen scraping accesses user’s data and
functions by impersonating a user through password sharing. This brittle, inefficient, and insecure practice
creates security vulnerabilities which require financial institutions to allow what appears to be an automated
attack against their applications.
This document is Part 1 of FAPI Security Profile 1.0. It specifies a baseline security profile of OAuth that is
suitable for protecting APIs with a moderate inherent risk. Importantly, this profile does not provide non-
repudiation (signing of authorization requests and responses) and sender-constrained access tokens. If such
features or a higher level of security is desired, the use of FAPI Security Profile 1.0 - Part 2: Advanced is
recommended.
Although it is possible to code an OpenID provider and relying party from first principles using this
specification, the main audience for this specification is parties who already have a certified implementation
of OpenID Connect and want to achieve a higher level of security. Implementers are encouraged to understand
the security considerations contained in Section 7.6 before embarking on a ‘from scratch’ implementation.
© ISO/IEC 2026 – All rights reserved
v
Notational conventions
The key words "shall", "shall not", "should", "should not", "may", and "can" in this document are to be
interpreted as described in ISO/IEC Directives, Part 2. These key words are not used as dictionary terms such
that any occurrence of them shall be interpreted as key words and are not to be interpreted with their natural
language meanings.
© ISO/IEC 2026 – All rights reserved
vi
International Standard ISO/IEC 25791-1:2026(en)

Information technology — OpenID Connect FAPI Security
Profile 1.0 —
Part 1:
Baseline
1. Scope
This document specifies the method for an application to:
● obtain OAuth tokens in a moderately secure manner for access to protected data;
● use OpenID Connect (OIDC) to identify the customer (user); and
● use tokens to access REST APIs in a moderately secure manner.
2. Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
RFC 4122 - A Universally Unique IDentifier (UUID) URN Namespace
RFC 6749 - The OAuth 2.0 Authorization Framework
RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients
RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet
Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
BCP212 - OAuth 2.0 for Native Apps
BCP195 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer
Security (DTLS)
IANA TLSP - Transport Layer Security (TLS) Parameters
OIDC - OpenID Connect Core 1.0 incorporating errata set 2
RFC 8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
OIDD - OpenID Connect Discovery 1.0 incorporating errata set 2
RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
© ISO/IEC 2026 – All rights reserved
3. Terms and definitions
For the purpose of this document, the terms defined in RFC 6749, RFC 6750, RFC 7636, OIDC apply.
4. Symbols and abbreviated terms
API - application programming interface
CAA - certificate authority authorization
CORS – cross-origin resource sharing
CSRF - cross site request forgery
DNSSEC - domain name system security extensions
FAPI - FAPI
HTTP - hypertext transfer protocol
IP - internet protocol
JARM - JWT secured authorization response mode
JSON - javaScript object notation
JWT - JSON web token
OIDF - OpenID foundation
RP - relying party
RSA - Rivest-Shamir-Adleman
REST - representational state transfer
TLS - transport layer security
URI - uniform resource identifier
UTF - unicode transformation format
UUID - universally unique identifier
5. Baseline security profile
5.1 Introduction
The OIDF FAPI security profile specifies security requirements for API resources protected by the OAuth 2.0
Authorization Framework that consists of RFC 6749, RFC 6750, RFC 7636, and other specifications.
© ISO/IEC 2026 – All rights reserved
FAPI Security Profile 1.0 - Part 1: Baseline and Part 2: Advanced specify different levels of security. The
characteristics required of the tokens are different, and the methods to obtain tokens are explained separately.
This document specifies the baseline security provisions.
5.2 Baseline security provisions
5.2.1 Introduction
Some APIs, such as ones that provide potentially sensitive information, require a greater level of protection
than basic RFC 6749 requires. FAPI provides such greater protection.
As a profile of the OAuth 2.0 Authorization Framework, this document mandates the following to the baseline
profile of the FAPI Security Profile 1.0.
5.2.2 Authorization server
5.2.2.0 Authorization server provisions
The authorization server
1. shall support confidential clients;
2. should support public clients;
3. shall provide a client secret that adheres to the requirements in Section 16.19 of OIDC if a symmetric
key is used;
4. shall authenticate the confidential client using one of the following methods:
1. Mutual TLS for OAuth client authentication as specified in Section 2 of RFC 8705, or
2. client_secret_jwt or private_key_jwt as specified in Section 9 of OIDC;
5. shall require and use the key length permitted by BCP195;
6. shall not use algorithms deprecated in IANA TLSP;
7. shall require RFC 7636 with S256 as the code challenge method;
8. shall require redirect URIs to be pre-registered;
9. shall require the redirect_uri in the authorization request;
10. shall require the value of redirect_uri to exactly match one of the pre-registered redirect URIs;
11. shall require user authentication to an appropriate level of assurance for the operations the client will
be authorized to perform on behalf of the user;
12. shall require explicit approval by the user to authorize the requested scope if it has not been previously
authorized;
13. shall reject an authorization code (Section 1.3.1 of RFC 6749) if it has been previously used;
14. shall return token responses that conform to Section 4.1.4 of RFC 6749;
15. shall return the list of granted scopes with the issued access token if the request was passed in the
front channel and was not integrity protected;
16. shall provide non-guessable access tokens, authorization codes, and refresh token (where applicable),
with sufficient entropy such that the probability of an attacker guessing the generated token is
computationally infeasible as per RFC 6749 Section 10.10;
17. should clearly identify the details of the grant to the user during authorization as in 16.18 of OIDC;
© ISO/IEC 2026 – All rights reserved
18. should provide a mechanism for the end-user to revoke access tokens and refresh tokens granted to a
client as in 16.18 of OIDC;
19. shall return an invalid_client error as defined in 5.2 of RFC 6749 when mis-matched client
identifiers were provided through the client authentication methods that permits sending the client
identifier in more than one way;
20. shall require redirect URIs to use the https scheme;
21. should issue access tokens with a lifetime of under 10 minutes unless the tokens are sender-
constrained;
22. shall support OIDD, may support RFC 8414 and shall not distribute discovery metadata (such as the
authorization endpoint) by any other means; and
23. shall require the response_type values code or code id_token.
NOTE: The use of refresh tokens instead of long-lived access tokens for both public and confidential clients is
recommended.
NOTE: The FAPI Security Profile 1.0 authorization server may limit the scopes for the purpose of not
implementing certain APIs.
NOTE: Clients are expected to treat access tokens as opaque strings and replay them as is. Authorization
servers can issue unstructured or structured access tokens (for example, a signed JWT).
NOTE: The requirement to return the list of granted scopes allows clients to detect when the authorization
request was modified to include different scopes. Servers must still return the granted scopes per section 5.1
of RFC 6749 if they are different from those requested.
5.2.2.1 Returning authenticated user's identifier
Further, if it is desired to provide the authenticated user's identifier to the client in the token response, the
authorization server:
1. shall support the authentication request as in Section 3.1.2.1 of OIDC;
2. shall perform the authentication request verification as in Section 3.1.2.2 of OIDC;
3. shall authenticate the user as in Section 3.1.2.2 and 3.1.2.3 of OIDC;
4. shall provide the authentication response as in Section 3.1.2.4 and 3.1.2.5 of OIDC depending on the
outcome of the authentication;
5. shall perform the token request verification as in Section 3.1.3.2 of OIDC; and
6. shall issue an ID Token in the token response when openid was included in the requested scope
as in Section 3.1.3.3 of OIDC with its sub value corresponding to the authenticated user and
optional acr value in ID Token.
5.2.2.2 Client requesting openid scope
If the client requests the openid scope, the authorization server
1. shall require the nonce parameter defined in Section 3.1.2.1 of OIDC in the
...