Wiki · Concept · Last reviewed June 25, 2026

FAPI 2.0 Security Profile

FAPI 2.0 Security Profile is the OpenID Foundation high-security OAuth profile for APIs where token replay, redirect tampering, weak client authentication, and incomplete implementations would create material harm.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, FAPI, PAR, PKCE, DPoP, mTLS

Definition

FAPI 2.0 Security Profile is an OpenID Foundation Final specification published on February 22, 2025 by D. Fett, D. Tonge, and J. Heenan. It profiles OAuth 2.0 for high-value APIs. The work grew out of financial API security, but the specification says the pattern is also intended for sensitive data in domains such as health and government.

The profile is not a new OAuth grant. It narrows how clients, authorization servers, and resource servers deploy OAuth and related standards. It aims to meet the FAPI 2.0 Attacker Model and follows RFC 9700, the OAuth 2.0 Security Best Current Practice.

For AI agents, FAPI matters where a tool runtime connects to payment, banking, data-export, government, workplace, or internal administration APIs. It gives architects a source-backed authorization baseline. It does not decide whether an agent should perform a task.

How It Works

The profile layers already-standardized controls. Authorization servers must offer TLS-protected endpoints, reject the resource owner password credentials grant, support only confidential clients, and issue only sender-constrained tokens. The sender constraint is provided with OAuth mutual TLS under RFC 8705 or OAuth DPoP under RFC 9449.

The authorization flow is narrowed around the authorization-code response type. The authorization server must support client-authenticated Pushed Authorization Requests, reject authorization requests sent without PAR, require PKCE with S256, require the redirect_uri inside the pushed request, return an iss parameter under RFC 9207, and issue authorization codes with a maximum lifetime of 60 seconds.

Clients must use authorization server metadata from OpenID Connect Discovery or RFC 8414, obtain issuer URLs from an authoritative source over a secure channel, and verify that the issuer URL matches the metadata. These checks reduce mix-up, redirect, and metadata-substitution failures.

Agent Context

Agent infrastructure stretches ordinary OAuth assumptions. A user may delegate work to an application, the application may route through a model, and a connector may hold a token that can move money, change records, or export private data. FAPI does not make that chain socially trustworthy, but it gives the API layer stronger evidence about who is calling, where the token can be used, and whether the request came through the approved channel.

The comparison is with bearer-token integrations. A leaked bearer token can be replayed by whoever has the string unless other controls stop it. FAPI's sender-constrained-token requirement ties token use to a client-held certificate or signing key. PAR moves sensitive request details off the browser redirect. PKCE and issuer identification tighten the code exchange and response-processing path.

Governance and Safety

The governance trap is treating FAPI conformance as a conclusion instead of evidence. A conformant flow can still authorize the wrong business action, expose too much data, or hide the human reason for a tool call. FAPI hardens the corridor. It does not write the policy for what should pass through it.

Agent deployments need records beyond OAuth success: user, client, authorization server, resource server, scope, sender-constraining method, issuer, redirect URI, tool name, requested action, approval surface, and enforcement decision. Without that record, investigators see a valid token but not the decision that created it.

Defense Pattern

Source Discipline

Claims about FAPI should identify the profile version, role, and conformance target: authorization server, client, resource server, or ecosystem profile layered on top. "Financial-grade" is not enough. A useful report should say whether the deployment uses the February 2025 Final Security Profile, which sender-constraining method is supported, whether PAR is mandatory, and whether PKCE S256 and RFC 9207 issuer handling are enforced.

FAPI should not be confused with OpenID Connect alone, mTLS alone, DPoP alone, PKCE alone, JARM, OAuth 2.1, API keys, workload identity, or a legal conclusion that consent was valid.

Spiralist Reading

Spiralism reads FAPI as an argument against wandering authority: authenticated client, pushed request, short-lived code, issuer check, proof-bound token, resource validation.

Open Questions

Sources

Return to Wiki