Wiki · Concept · Last reviewed July 10, 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 Published: June 25, 2026 Modified: July 10, 2026 Last reviewed: July 10, 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 is a high-security profile of OAuth 2.0 for APIs where unauthorized access, token replay, redirect tampering, weak client authentication, or implementation mistakes would create material harm.

The profile is not a new OAuth grant and not a replacement for OpenID Connect. It narrows how clients, authorization servers, and resource servers use OAuth and related standards. It aims to meet the FAPI 2.0 Attacker Model, follows RFC 9700, the OAuth 2.0 Security Best Current Practice, and is accompanied by formal security analysis under the stated attacker model.

FAPI grew out of financial API security, but the current specification is written as a general-purpose high-security profile. The Security Profile says OAuth is increasingly used in higher-security settings such as open banking, eHealth, eGovernment, and electronic signatures. For AI agents, the relevance is practical: agent connectors increasingly touch payment, banking, data-export, government, workplace, healthcare, and internal administration APIs. FAPI can harden the authorization corridor. It does not decide whether the agent should perform the business action.

Snapshot

Current Context

As of July 10, 2026, the FAPI 2.0 Security Profile and FAPI 2.0 Attacker Model are OpenID Final Specifications. The OpenID Foundation announced approval of both on February 19, 2025, and the Security Profile text is dated February 22, 2025. A Final Specification gives implementers intellectual-property protections under the OpenID process and is not subject to further revision.

The companion FAPI 2.0 Message Signing specification became Final on September 25, 2025, with OpenID approval announced on September 26, 2025. It builds on the Security Profile and adds signing and verification of certain FAPI-based requests and responses for non-repudiation. Message Signing is therefore adjacent but separate: a deployment can discuss Security Profile conformance without claiming Message Signing conformance unless the signed-request and signed-response requirements are actually implemented.

OpenID announced final-version conformance tests and certifications for FAPI 2.0 Security Profile and Message Signing on July 9, 2025, for authorization servers and OAuth clients. Certification is useful procurement evidence, but it is still a profile-specific implementation claim. It does not prove the whole API ecosystem, consent screen, resource-server policy, fraud control, agent workflow, or data-governance program is safe.

FAPI 2.0 also matters because it aligns with the broader OAuth hardening path. RFC 9700 was published in January 2025 as the OAuth 2.0 Security Best Current Practice. FAPI uses that security baseline and further constrains choices that ordinary OAuth leaves open. For agentic systems, the result is a stronger default for high-consequence connectors than generic bearer-token OAuth.

Scope and Non-Goals

The Security Profile covers how OAuth clients obtain sender-constrained tokens from authorization servers and use them securely with resource servers. It defines requirements for network protection, authorization-server behavior, client behavior, resource-server checks, cryptographic algorithms, token handling, privacy, and secure implementation.

Its formal assurance depends on the mandatory behaviors staying intact. The specification says ecosystems may further narrow optional choices, but a compliant profile must not remove or override mandatory behavior because doing so is likely to invalidate the formal security analysis and reduce security unpredictably.

The profile's requirements also imply a boundary around client type. It requires confidential clients and client authentication. If an agent connector, mobile app, browser extension, or local automation cannot protect a client credential or signing key, it should not be described as FAPI 2.0 Security Profile compliant without a precise explanation of the client design and conformance target.

FAPI does not define fine-grained business authorization by itself. It can carry scopes and can be paired with Rich Authorization Requests when scopes are not expressive enough, but the ecosystem still has to define accounts, payment limits, beneficiaries, records, data fields, revocation rules, fraud checks, and human approval requirements.

How It Works

The profile layers already-standardized controls. All parties use TLS-protected endpoints. Authorization servers reject the resource owner password credentials grant, support only confidential clients, require client authentication, 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 browser-facing authorization flow is narrowed around the authorization-code response type. Authorization servers 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, reject reused authorization codes, and avoid redirect responses that could forward user credentials to a third party.

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. Clients using authorization-code flow must use PAR, PKCE S256, and issuer checking. These controls reduce mix-up, redirect, metadata-substitution, code-injection, and token-replay failures.

Resource servers are not passive receivers. The Security Profile requires them to accept access tokens only in HTTP headers or DPoP-style requests, not query parameters; verify token validity, integrity, expiration, and revocation status; verify that the authorization represented by the token is sufficient for the requested resource access; and support and verify mTLS-bound or DPoP-bound access tokens.

The cryptographic rules are also constrained. When creating or processing JWTs, parties must follow RFC 8725, use allowed modern signing algorithms such as PS256, ES256, or EdDSA with Ed25519, and reject the none algorithm. Tokens and authorization codes need enough entropy to make guessing infeasible.

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. Resource-server verification turns the token from a credential string into a checked authorization statement.

For remote tools, MCP servers, and enterprise connectors, the governance question becomes: is this a high-value API that should demand FAPI-level controls before an agent can act? Payments, brokerage, clinical records, identity proofing, tax data, HR systems, procurement systems, code repositories, ticketing systems, customer exports, and privileged internal APIs are likely candidates.

FAPI still cannot stop the legitimate sender from being induced to act by prompt injection, poisoned tool output, overbroad scope, or a bad approval screen. If the authorized agent process signs a DPoP proof or uses its own mTLS-bound credential for the wrong purpose, the protocol may work exactly as designed while governance fails above it.

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.

FAPI privacy considerations also matter for agent systems. The specification calls out inadequate notice, inadequate choice, misuse of data, collection minimization violations, unsolicited personal data from resource servers, authorization-server tracking, client tracking, client misidentification, and user misunderstanding of what data will be released. Those are not theoretical side issues when an agent can ask for a broad connector grant and then perform many downstream actions.

For regulated or public-interest uses, FAPI evidence should connect to an AI system inventory, agent identity record, audit trail, procurement file, change-management process, and incident response plan. A high-security OAuth profile is strongest when it is paired with least privilege, human oversight, revocation, data minimization, and post-action review.

Minimum Evidence Record

A governance-grade FAPI record should make the conformance claim specific without storing the secrets themselves.

Failure Modes

Conformance laundering. A vendor cites FAPI while only one component, flow, or older draft profile was tested.

Public-client mismatch. A browser, mobile, local, or extension-based agent cannot protect the credential required for confidential-client behavior, but the deployment is still described as FAPI-secured.

Sender-bound misuse. The token is not stolen; the legitimate agent or connector is tricked into using its bound credential for an unsafe action.

Resource-server gap. The authorization flow is hardened, but the resource server accepts query tokens, skips revocation checks, ignores sender constraint, or fails to verify authorization sufficiency for the resource requested.

Scope theater. A broad scope or vague consent label hides the concrete account, payment, file, patient record, or administrative action.

Message-signing confusion. A system claims FAPI 2.0 Security Profile conformance and lets readers infer non-repudiation properties that require the separate Message Signing profile.

Privacy overreach. A technically valid authorization releases more data than needed, returns unsolicited personal data, or gives users poor notice about what an agent will access.

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, whether PKCE S256 and RFC 9207 issuer handling are enforced, and whether resource-server checks were tested.

Separate the FAPI 2.0 Security Profile from FAPI 2.0 Message Signing. The Security Profile can establish a hardened OAuth flow. Message Signing adds signing of selected requests and responses for non-repudiation. A source that proves one does not automatically prove the other.

FAPI should not be confused with OpenID Connect alone, mTLS alone, DPoP alone, PKCE alone, JAR, JARM, OAuth 2.1, API keys, workload identity, or a legal conclusion that consent was valid. Those mechanisms may be part of a FAPI ecosystem, but none of them is a substitute for the full profile.

For current claims, prefer the OpenID Final specification, OpenID final-approval announcement, OpenID conformance-test announcement, IETF RFCs, formal analysis papers or OpenID analysis announcements, and regulator or ecosystem profiles that explicitly adopt FAPI. Vendor implementation pages can establish product support, but they should not be used as the source for the standard's requirements.

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.

The protocol does not make the agent wise. It makes the path of authority harder to fake. The human question remains whether the authority should have been granted at all.

Open Questions

Sources

Return to Wiki