FAPI 2.0 for open banking: the OAuth checklist developers need

FAPI 2.0 is an OAuth profile for high-value APIs such as open banking. It tightens plain OAuth by requiring the authorization code flow with PKCE, pushed authorization requests, confidential clients and sender-constrained access tokens, so a stolen token is not enough to call the API.

Why a profile at all

OAuth leaves many choices open. Banks and third party providers have to agree on exact behavior, and an open choice is where attacks live. The OpenID Foundation's Financial-grade API Security Profile 2.0 narrows those choices. Whether a given regime requires it is a matter for that regime, so check your local rules.

What authorization servers must do

Based on the profile's section 5.3.2:

• Issue only sender-constrained access tokens, using mutual TLS or DPoP.
• Authenticate clients with mutual TLS or private_key_jwt, and support only confidential clients.
• Require PKCE with the S256 method.
• Support client-authenticated pushed authorization requests, and reject authorization requests that did not arrive by that route.
• Require response_type of code.
• Limit authorization code lifetime to 60 seconds and reject codes that were already used.
• Return the iss parameter so clients can detect mix-up attacks.
• Reject http redirect URIs, except for native loopback clients, and avoid open redirectors.

What clients must do

From section 5.3.3:

• Use the authorization code grant with a fresh PKCE challenge for each request.
• Push the request first, then send only client_id and request_uri to the authorization endpoint.
• Check the iss value in the response.
• Support mutual TLS, DPoP or both for sender-constrained tokens, and mutual TLS or private_key_jwt for client authentication.

What sender-constrained means

A normal bearer token works for whoever holds it. A sender-constrained token is bound to a key held by the client, so a copy lifted from logs or a proxy fails without that key. That is the biggest practical gain for banking APIs, where a leaked token can move money or read statements.

Rollout order that works

1. Turn on PKCE with S256 everywhere first. It is cheap.
2. Add pushed authorization requests, which also keep request details out of the browser URL.
3. Move to confidential clients with key based authentication.
4. Add sender-constrained tokens last, since this needs the most client work.
5. Test code reuse, redirect handling and issuer checks as negative tests.

Quick check

Sources

• OpenID Foundation: FAPI Security Profile 2.0

Last reviewed: 19 October 2026.