FAPI (Financial-grade API)

What it is

FAPI, the Financial-grade API profile from the OpenID Foundation, is a tightened security profile layered on OAuth 2.0 and OpenID Connect. It exists because plain OAuth, while flexible, leaves choices that are unsafe for high-value APIs like banking and payments. FAPI removes that ambiguity and mandates the strong options.

How it works

FAPI raises the bar with requirements such as:

• Sender-constrained tokens (mutual TLS or DPoP) so a stolen token cannot be replayed by another client.
• Pushed Authorization Requests (PAR) so request parameters are sent over a back channel and cannot be tampered with.
• Strong client authentication and signed request objects.

What FAPI 2.0 actually requires

The FAPI 2.0 Security Profile turns OAuth's options into rules. For authorization servers it says, among other requirements:

• Confidential clients only. Public clients are not supported.
• Sender-constrained access tokens only, using either mutual TLS (RFC 8705) or DPoP (RFC 9449).
• Strong client authentication: mutual TLS or private_key_jwt. Shared client secrets are out.
• Pushed authorization requests required (RFC 9126): the server rejects authorization requests that were not pushed, and rejects pushed requests without client authentication.
• Code flow only, with PKCE S256, and the redirect_uri required in the pushed request.
• Issuer identification in the authorization response (RFC 9207), to stop mix-up attacks.
• Authorization codes valid for at most 60 seconds.
• No resource owner password grant, and no refresh token rotation except in extraordinary circumstances. The profile notes that rotation adds no security for confidential clients with sender-constrained tokens and causes failures whenever a client misses the new refresh token.
• No http redirect URIs: authorization responses must not travel over unencrypted connections.

The profile is formally analysed against a published FAPI 2.0 Attacker Model, and it states that a profile built on top must not remove or override mandatory behavior, since that could invalidate the security analysis. It also follows the OAuth 2.0 Security BCP (RFC 9700).

FAPI 2.0 Message Signing adds signing of authorization requests, authorization responses, introspection responses and ID tokens for ecosystems that need non-repudiation, for example to prove later exactly what a payment instruction said.

Status

As of 5 November 2026, per the FAPI working group's specifications page:

The working group "strongly recommends that all new ecosystems adopt FAPI 2.0" and that existing FAPI 1.0 ecosystems plan a transition. FAPI 1.0 is widely deployed in open banking regimes (UK, Brazil, Australia and others). FAPI 2.0 is simpler to implement than FAPI 1.0 Advanced and is the current target for new implementations.

FAPI, OAuth 2.1 and AI agents

FAPI 2.0 is roughly what OAuth 2.1 would look like with every option set to the strict choice. OAuth 2.1 requires PKCE and drops the implicit and password grants; FAPI 2.0 additionally requires PAR, sender-constrained tokens and asymmetric client authentication. That is relevant beyond banking. Agents that move money or touch regulated data are high-value clients holding tokens in processes that read untrusted input, the exact case where a stolen bearer token is worst. Neither MCP nor A2A requires sender-constrained tokens today, as SWI's Agent Identity Standards Map 2026 records, so a FAPI 2.0 authorization server is one of the few ways to get DPoP or mTLS binding enforced by policy rather than by client goodwill.

When to use it

When you expose APIs that move money or highly sensitive data, or when a regulator or open-banking scheme requires it. For ordinary consumer login, standard OIDC is sufficient.

Pitfalls

• FAPI is demanding to implement correctly; use a certified provider rather than building it yourself.
• Conformance matters: look for OpenID Foundation certification against the FAPI 2.0 test plans on any platform you rely on, and confirm which profile (FAPI 1.0 Advanced or FAPI 2.0) and which sender-constraining method (mTLS or DPoP) it was certified for.
• Ecosystem profiles narrow the choices further. A national open banking profile may require mTLS where FAPI 2.0 allows DPoP, so read the ecosystem profile, not only the base specification.
• Clock skew: FAPI 2.0 tells servers to accept JWTs with iat or nbf up to 10 seconds in the future and to reject them beyond 60 seconds, and it suggests clients on user devices use the server's HTTP Date header to correct their clocks.

Related

Glossary: FAPI, PAR, DPoP. Standards: OAuth 2.0, OAuth 2.1, OpenID Connect, MCP authorization. Glossary: proof of possession, mTLS, PSD2.

Who wrote it

FAPI came out of the OpenID Foundation working group with Torsten Lodderstedt, and Daniel Fett led its formal security analysis. Nat Sakimura chairs the OpenID Foundation. More in the experts directory.