OAuth 2.0 for Financial-Grade API, or FAPI, is a security profile for OAuth 2.0 and OpenID Connect used to protect high-value APIs. It tightens requirements for client authentication, token handling, redirect control and proof of possession so authorisation can be stronger and harder to intercept or replay.
What FAPI actually changes in OAuth 2.0
FAPI is not a new authorisation model. It is a stricter security profile for OAuth 2.0 and OpenID Connect that raises the bar for client authentication, token protection, redirect handling and proof of possession so high-value API traffic is harder to intercept, tamper with or replay.
That matters because the underlying OAuth flow is often used where a stolen bearer token, weak client authentication or a loose redirect rule can turn one successful login into broad API access. FAPI narrows those failure modes by specifying stronger combinations of protocol features instead of leaving each implementation to choose its own security profile.
Why FAPI exists in high-value API ecosystems
FAPI emerged because financial and other sensitive API ecosystems need more than generic OAuth correctness. In ordinary deployments, the weakest link is often not the grant type itself, but the way clients authenticate, how codes and tokens are handled in transit, and whether an intercepted artefact can be replayed elsewhere.
FAPI’s design focus is therefore defensive consistency. It reduces reliance on shared secrets and bearer-only assumptions, and it pushes deployments toward stronger client authentication and sender-constrained tokens. For the underlying OAuth and OpenID Connect building blocks, see RFC 6749: The OAuth 2.0 Authorization Framework and OpenID Connect Core 1.0.
For readers comparing modern hardening approaches, RFC 9700: Best Current Practice for OAuth 2.0 Security is useful context because it frames the broader security direction that FAPI operationalises more strictly for high-assurance deployments.
Core security controls inside a FAPI deployment
The practical security value of FAPI comes from the control set it makes non-optional or much stricter. That typically includes stronger client authentication, use of PKCE where appropriate, tighter redirect URI control, audience restriction, short-lived tokens, and sender-constrained mechanisms such as mTLS or DPoP so a stolen token is less useful outside its original context.
Those controls are complementary, not interchangeable. Strong client authentication reduces impersonation risk, redirect discipline reduces code interception risk, and proof of possession reduces replay risk after token theft. When these controls are combined, the API trust boundary becomes much harder to abuse through a single weak implementation choice.
Where deployments need a deeper implementation reference, FAPI 2.0 Security Profile Implementation Guide covers PAR, PKCE, sender-constrained tokens, crypto rules, Message Signing, conformance tests and migration, while OAuth 2.1, GNAP and FAPI Guide places FAPI in the wider modern OAuth hardening landscape.
How FAPI changes validation, exposure review and API design
FAPI is best treated as a profile to validate, not just a feature list to enable. Organisations need to check which clients, redirect paths, token types and authorisation servers actually participate in the high-value flow, because partial adoption often leaves a weaker path exposed alongside the protected one.
That review should include endpoint inventory, external exposure, mobile and web client behaviour, token lifetimes, and whether the runtime honours proof-of-possession and audience binding end to end. A gateway or reverse proxy can help, but it cannot compensate for a broken OAuth design if tokens can still be replayed or routed to the wrong resource.
For API-specific risk framing, OWASP API Security Top 10 is a useful companion reference, especially where broken authentication or broken authorisation can undermine an otherwise well-structured flow.
Risk and Threat Considerations
FAPI exists because ordinary OAuth deployments can fail in ways that are especially damaging for high-value APIs. If client authentication is weak, a stolen code or token can be replayed by an attacker; if redirect handling is loose, authorisation responses can be intercepted; and if tokens are not bound to the presenting client, theft can become immediate access.
Failure mechanism: An attacker abuses bearer-style assumptions, intercepts or steals an OAuth artefact, and reuses it against a valuable API before the organisation detects the abuse or revokes the session.
Impact: The result can be unauthorised account access, fraudulent API calls, data exposure, or downstream compromise of connected services that trust the same authorisation path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth 2 and OpenID Connect | FAPI is a stricter OAuth/OIDC security profile for high-value API authentication. |
| Recommendation — Apply V10 requirements to harden OAuth and OIDC flows used by the API. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | FAPI addresses authentication weaknesses that can let stolen tokens or codes be replayed. |
| API5 — Broken Function Level Authorization | High-value OAuth APIs still need strong function-level access control beyond token issuance. | |
| Recommendation — Validate API authentication paths so intercepted credentials cannot be reused. Enforce function-level authorization on every protected API action. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | FAPI relies on stronger handling of client secrets, assertions and token material. |
| IA-9 — Service Identification and Authentication | FAPI commonly secures service-to-service API access where clients must prove identity strongly. | |
| Recommendation — Manage authenticators with short lifetimes, rotation and protection against replay. Authenticate API clients with mechanisms that resist impersonation and token theft. | ||
Practitioner Guidance
Why practitioners should care: FAPI is most valuable where the API itself is a business control point, not just a technical integration surface. In those cases, implementation detail becomes security policy, so small deviations in client authentication, redirect handling or token binding can create disproportionate exposure.
What to watch for: The common mistake is treating FAPI as “OAuth plus a few extras” rather than a constrained profile with specific security expectations. If a deployment still relies on broad bearer-token trust, loose redirect registration or inconsistent client assurance, the profile has not really been achieved.
Practitioner takeaway: Use FAPI as a conformance and design baseline for high-value APIs, then verify the full request path, not just the token endpoint, because replay resistance is only as strong as the weakest step in the flow.
Related resources from NHI Mgmt Group
- How should security teams implement financial-grade OAuth in regulated API environments?
- How should security teams implement financial-grade API security for sensitive banking and payments workloads?
- Why does a software statement add security value in financial-grade API onboarding?
- How should teams implement financial-grade OAuth for open banking?