The FAPI 2.0 Security Profile is the OpenID Foundation’s current high-security profile of OAuth 2.0, published as a Final specification on 22 February 2025. It admits only confidential clients, requires pushed authorization requests, PKCE with S256 and sender-constrained access tokens (mTLS or DPoP), and is designed against an explicit attacker model rather than a list of best practices.
FAPI 2.0 Security Profile
The FAPI 2.0 Security Profile is the second generation of the OpenID Foundation’s FAPI work: an API security profile “suitable for high-security applications based on the OAuth 2.0 Authorization Framework.” It reached Final status on 22 February 2025. It was born in open banking, but the specification says plainly that it applies anywhere the data is high value — health, government and beyond. Germany’s federal API authorization blueprint builds its profile for high and very-high protection needs on FAPI 2.0.
- Confidential clients only - Clients must authenticate with mutual TLS or
private_key_jwt. Shared secrets and public clients are out. - PAR is not optional - Authorization requests go through Pushed Authorization Requests. The authorization server rejects any that don’t, and the front channel carries only
client_idandrequest_uri. - PKCE with S256 everywhere - PKCE replaces
stateas the CSRF defense, and the client generates a fresh challenge for every request. - Sender-constrained tokens only - Access tokens are bound through mTLS (RFC 8705) or DPoP (RFC 9449). FAPI 1.0 allowed mTLS only.
codeis the only response type - ID tokens move to the back channel. The authorization server must returnissin the authorization response (RFC 9207) to stop mix-up attacks.- Tight numbers - Authorization codes live at most 60 seconds and are single-use. PAR
request_urivalues expire in under 600 seconds. Credentials carry at least 128 bits of entropy. - A fixed cryptography floor - TLS 1.2 or later, JWTs signed with PS256, ES256 or EdDSA (Ed25519), and never
none. - Built on an attacker model - A companion FAPI 2.0 Attacker Model states the security goals, and the profile has been formally analyzed against it.
Compared with FAPI 1.0, the profile is shorter and stricter. JAR and JARM give way to PAR and a plain code response, redirect URIs travel in the pushed request instead of being pre-registered, and DPoP joins mTLS as a sender-constraining option. Message-level signing lives in a separate FAPI 2.0 Message Signing specification, for ecosystems that need non-repudiation. For an API program, FAPI 2.0 is the easiest way to get a high-assurance OAuth stack without writing your own profile: point to it, and pass the OpenID Foundation certification suite. See Profile, Don’t Invent for how Germany did exactly that.
Industry: Finance
Governed by these regulations
A standard is the machine-readable contract; a regulation is the law that requires it. These are the regulations that mandate or drive this standard, catalogued at regulations.apievangelist.com.
Strong Customer Authentication (SCA)
The PSD2 security requirement financial-grade profiles operationalize.
Related standards
Standards this one builds on, supersedes, profiles or is commonly deployed beside.
FAPI
The FAPI family page — FAPI 1.0 Baseline/Advanced and FAPI 2.0 together.
OAuth Security Best Current Practice
FAPI 2.0 is built on the Security BCP (RFC 9700) plus a formal attacker model.
Pushed Authorization Requests
Mandatory — the authorization server rejects any request not sent through PAR (RFC 9126).
PKCE
Mandatory with the S256 challenge method; it replaces state-based CSRF protection.
DPoP (Demonstrating Proof of Possession)
One of the two permitted ways to sender-constrain access tokens (RFC 9449).
Mutual TLS
The other sender-constraining method, and one of two client authentication methods (RFC 8705).
private_key_jwt
The other permitted client authentication method.
OpenID Connect
FAPI 2.0 references OIDC Core and Discovery; ID tokens travel back-channel only.
Referenced on the API Evangelist blog
Where this standard shows up across sixteen years of my writing at apievangelist.com — how it fits into API design, governance, and the agentic turn.