OIDF · Final (OIDF FAPI WG)
fapi-security-profile-2_0-final
If you are connecting an agent to an open-banking API, the bank will not take 'we used OAuth 2.0'. They will take FAPI 2.0. It is also a checklist for any high-risk agent tool.
At a glance
Actors
01
High-value APIs (open banking, anything an agent could drain) need a profile of OAuth that has been argued against an attacker model. FAPI 2.0 Security Profile is that profile: PAR, PKCE S256, sender-constrained tokens (mTLS and/or DPoP), confidential clients only, exact redirects, iss in the response, 60-second authorization codes. If you are connecting an agent to an open-banking API, the bank will not take 'we used OAuth 2.0'.
It follows RFC 9700 and has been formally analysed against the FAPI attacker model. Do not assume FAPI 1.0 (JWS request objects, different constraints) is the same profile.
02
Confidential clients only — a public CLI agent is not FAPI 2.0 compliant without a confidential BFF. Authorization servers and resource servers have paired shalls. Public clients, implicit, password grants, and unconstrained Bearer tokens are out.
03
Not a new grant. Constrain authorization-code or CIBA: sender-constrained access tokens via mTLS (RFC 8705) and/or DPoP (RFC 9449); PAR required (reject authorize without PAR); PKCE S256; client authentication via private_key_jwt or mTLS; iss in authorization response (RFC 9207); no http redirects except native loopback; authorization codes ≤ 60 seconds; clock skew rules for JWT iat/nbf (accept 0–10 seconds future, reject > 60). TLS 1.2+ per BCP 195.
04
Flow 1
Confidential client authenticates and POSTs PAR with PKCE S256, redirect_uri, resource.
Redirect with request_uri only. User authenticates. Response includes iss.
Token request with client auth and DPoP or mTLS. Code lifetime already ticking (≤ 60s).
RS requires the same sender constraint. Step-up if the call is extra-sensitive.
05
A security profile wrapping OAuth authorization and (optionally) OIDC authentication. Identity is still OIDC if you asked for openid. Authorization is the constrained token.
06
FAPI 2.0 is built on RFC 9700 then tightens.
Compatible direction; FAPI is stricter (confidential-only, PAR mandatory, PoP mandatory).
Mandatory.
One allowed PoP method.
The other allowed PoP method.
Supported flow under the same attacker model.
07
A local LLM wrapper is not a confidential client. Put FAPI behind a BFF or do not claim FAPI.
Request objects and JARM are FAPI 1-era headlines. FAPI 2's headline is PAR + PoP.
FAPI 2.0 tells ASes not to use refresh token rotation except in extraordinary circumstances (see the spec's Note 1). Do not cargo-cult SPA rotation into a FAPI AS.
08
OIDF FAPI 2.0 Security Profile Final. Stable enough that banks certify against it. https://openid.net/specs/fapi-security-profile-2_0-final.html
Use FAPI 2.0 when the agent's tools move money or equally sensitive data. Do not assume FAPI 1.0 (JWS request objects, different constraints) is the same profile.