FAPI 2.0: Financial-Grade API

What is FAPI 2.0?

The Financial-grade API (FAPI) Working Group at the OpenID Foundation publishes security profiles that tighten OAuth 2.0 and OpenID Connect for environments where the cost of a security failure is high. FAPI 2.0 reached Final status in 2025, superseding the earlier FAPI 1.0 Advanced profile.

Where standard OAuth 2.0 defines a flexible framework with many optional parameters, FAPI 2.0 makes a specific set of choices mandatory: particular grant types, particular client authentication methods, and particular token-binding mechanisms. The result is a profile that is harder to misconfigure and more resistant to known attack classes.

Why standard OAuth 2.0 is not enough

Standard OAuth 2.0 gives implementers significant latitude. A client may use no PKCE, authenticate with a plain client secret in the request body, and receive bearer tokens with no binding to the client. In a low-risk context these tradeoffs are acceptable. For an open banking API initiating a payment or reading a full account history, they are not.

The specific threats FAPI 2.0 addresses include:

• Authorization request tampering. An attacker modifying redirect URIs or scope parameters in the authorization request before it reaches the server.
• Authorization code interception. Capturing the code in the redirect before the legitimate client exchanges it.
• Token replay. Using a stolen access token from a different client or session.
• Weak client authentication. Shared secrets that can be phished or leaked from client-side storage.

FAPI 2.0 requirements

Pushed Authorization Requests (PAR)

In a standard authorization code flow, the client sends all parameters — redirect URI, scope, state, code challenge — as query parameters in a URL that the browser follows. Those parameters are visible in browser history, server logs, and referrer headers.

PAR (RFC 9126) moves the authorization parameters out of the URL. The client first makes a direct HTTPS POST to the authorization server's PAR endpoint, receives a short-lived request_uri, and then redirects the browser with only that reference. The actual parameters are never exposed in the browser. FAPI 2.0 mandates PAR.

PKCE with S256

PKCE (RFC 7636) is required and the code challenge method must be S256. The plain method provides weaker guarantees and is not permitted under FAPI 2.0. Combined with PAR, this eliminates authorization code interception as a realistic attack.

Sender-constraining: DPoP or mTLS

Standard OAuth 2.0 issues bearer tokens: any party that holds the token can use it. FAPI 2.0 requires that tokens be bound to the client that requested them, so a stolen token cannot be replayed by a different party.

Two mechanisms are permitted:

• DPoP (Demonstrating Proof of Possession, RFC 9449): the client generates an asymmetric key pair, includes a signed proof-of-possession JWT with each token request and API call, and the server binds the issued token to the public key. Works without PKI infrastructure.
• mTLS (mutual TLS, RFC 8705): the client presents a client certificate during the TLS handshake, and the issued token is bound to the certificate's thumbprint. Requires certificate management but integrates naturally with existing PKI setups.

Client authentication: private_key_jwt or mTLS

FAPI 2.0 requires strong client authentication at the token endpoint — client secrets are not permitted. Two methods are allowed: private_key_jwt (OpenID Connect Core), where the client signs a JWT assertion with its private key and the authorization server verifies it against the registered public key (typically via a JWKS URI); and mTLS, where the client certificate used in the TLS handshake serves as the authentication credential. Both prevent credentials from being phished or guessed — the private key or certificate private key never leaves the client.

Short-lived tokens and nonce

Access tokens must be short-lived to minimize the exposure window. When used with OpenID Connect, FAPI 2.0 requires a nonce in authorization requests to prevent replay of ID tokens across sessions — the authorization server must validate that the nonce in the ID token matches the one sent in the request.

FAPI 1.0 vs FAPI 2.0

FAPI 2.0 simplifies the profile in some areas — notably making OIDC optional — while tightening others. PAR replaces JAR (signed request objects) as the primary mechanism for protecting authorization request integrity, which is simpler to implement correctly.

Where FAPI 2.0 is used

FAPI adoption is driven by open banking and open finance regulations that require third-party providers to access financial data through secure, standardized APIs:

• UK Open Banking — the Open Banking Implementation Entity (OBIE) standard mandates FAPI compliance for account information and payment initiation.
• Brazil Open Finance — the Brazilian Central Bank's open finance framework requires FAPI 1.0 Advanced and is transitioning to FAPI 2.0.
• Australia CDR — the Consumer Data Right framework uses FAPI profiles for banking and energy sector APIs.
• EU PSD2 / FIDA — European banking and the upcoming Financial Data Access framework reference FAPI as the recommended security profile.
• Healthcare — SMART on FHIR uses FAPI-aligned profiles for securing health record APIs.

Testing FAPI 2.0 flows

OAuth 2.0 Playground lets you exercise the key mechanisms used in FAPI 2.0 flows against real authorization servers: authorization code with PKCE (S256), and private_key_jwt client authentication using browser-generated RSA key pairs published to a hosted JWKS endpoint. Note that FAPI 2.0 is scoped to confidential clients, and a browser-based tool is inherently a public client — so the playground is useful for verifying that your authorization server correctly enforces FAPI requirements, not for certifying a production client. For formal conformance testing, use the OpenID Foundation conformance suite.

For background on the standard OAuth 2.0 flows that FAPI builds on, see the OAuth 2.0 Introduction.