OAuth 2.1, GNAP and FAPI 2.0 Explained

Most OAuth deployments still allow patterns that the standards community now treats as unsafe, such as bearer tokens that work for anyone who steals them, loose redirect matching and grants that hand passwords to clients. Three efforts define what modern authorisation looks like: OAuth 2.1, which consolidates a decade of security advice into one specification; GNAP, a new protocol published as RFC 9635 that redesigns delegation from first principles; and FAPI 2.0, the OpenID Foundation's high-security profile built for open banking and other high-value APIs. This guide explains what each one changes, where they differ, how to adopt them in phases and how to verify the result. It is written for identity architects, API platform teams and security engineers who already know the OAuth 2.0 basics, which are covered in the OAuth 2.0 and OpenID Connect Guide.

Key takeaways

OAuth 2.1 is still an Internet-Draft. As of October 2026 the current version is draft-ietf-oauth-v2-1-16 (3 September 2026), a working group document not yet submitted to the IESG, so treat it as a target profile rather than an RFC.
The security baseline is already published. RFC 9700 (BCP 240, January 2025) carries most of the same rules today: no password grant, PKCE, exact redirect matching, sender-constrained tokens and no tokens in query strings.
FAPI 2.0 is final and prescriptive. The Security Profile and Attacker Model were published as final on 22 February 2025 and require PAR, PKCE with S256, confidential clients and tokens bound to mTLS or DPoP keys.
GNAP is a different protocol, not OAuth 3. RFC 9635 (October 2024) and RFC 9767 for resource servers replace scopes with structured access requests and bind tokens to client keys by default, but ecosystem support is far narrower than OAuth.
Agents and MCP are making OAuth 2.1 the default. The Model Context Protocol authorisation specification builds on the OAuth 2.1 draft and adds resource indicators, scope challenges and a ban on token passthrough.

The three specifications at a glance

Specification	Publisher and status	What it is	Typical use
OAuth 2.1 (draft-ietf-oauth-v2-1)	IETF OAuth working group; Internet-Draft -16, expires 7 March 2027; milestone to submit to the IESG in December 2026	A consolidation of RFC 6749, RFC 6750 and later security guidance into one core document	General purpose baseline for new authorisation servers, clients and APIs
RFC 9700, OAuth 2.0 Security Best Current Practice	IETF; BCP 240, January 2025; updates RFC 6749, 6750 and 6819	Normative security advice for OAuth 2.0 deployments	The citable standard for auditors today while OAuth 2.1 is in draft
FAPI 2.0 Security Profile	OpenID Foundation; Final, 22 February 2025	A strict profile of OAuth 2.0 with defined parameters, algorithms and timings, backed by a formal attacker model	Open banking, open finance, health and other high-value APIs
FAPI 2.0 Attacker Model and Message Signing	OpenID Foundation; both Final	The threat model the profile was analysed against, and optional signing of requests and responses for non-repudiation	Regulated ecosystems that need evidence of who requested what
GNAP, RFC 9635	IETF; Standards Track RFC, October 2024	A new delegation protocol that is not an extension of OAuth 2.0	Greenfield designs needing multiple tokens, flexible interaction or key-bound clients

What OAuth 2.1 changes

OAuth 2.1 adds little that is new: its value is one document with the safe defaults built in.

PKCE for the authorisation code grant: clients send a code_challenge, and authorisation servers must reject requests from public clients that do not include one. Use the S256 method; plain exposes the verifier.
Implicit grant removed: response_type=token is not part of OAuth 2.1. Browser applications use the authorisation code grant with PKCE.
Resource owner password credentials grant removed: RFC 9700 already says clients and servers must not use it. Any client still collecting user passwords to exchange for tokens needs to move to a redirect-based flow or, for machine access, to client credentials.
Exact redirect URI matching: authorisation servers compare the full string against registered values. The only flexibility is the port on loopback redirects for native apps.
Refresh token discipline: refresh tokens are bound to the scope and resources the owner consented to and are only ever sent to the authorisation server. For public clients, RFC 9700 requires refresh tokens to be either sender-constrained or rotated on each use.
No bearer tokens in query strings: tokens go in the Authorization header. RFC 9700 states that clients must not pass access tokens in URI query parameters, where they leak into logs, proxies and browser history.

Two further controls appear in the draft as SHOULD rather than MUST, and are where most real hardening happens: sender-constrained access tokens using DPoP (RFC 9449) or mutual TLS, and audience restriction so that a token issued for one API cannot be replayed at another. RFC 9700 recommends both, and adds the iss authorisation response parameter (RFC 9207) as the defence against mix-up attacks for clients that talk to more than one authorisation server.

Sender-constrained tokens in practice

Mechanism	How the binding works	Strengths	Watch points
DPoP (RFC 9449)	Client signs a `DPoP` header JWT (`typ` `dpop+jwt`) per request with claims `jti`, `htm`, `htu`, `iat` and `ath`; the token carries `cnf.jkt`, the key thumbprint; `token_type` is `DPoP`	Works at the application layer, including single page apps, mobile apps and agents behind TLS-terminating proxies	Track `jti` and use server nonces (`DPoP-Nonce`, `use_dpop_nonce` error) to limit pre-generated proofs; resource servers must reject DPoP tokens presented as Bearer; private key storage on the client decides the real strength
Mutual TLS (RFC 8705)	Token is bound to the client certificate thumbprint presented on the TLS connection	Strong where a PKI and workload certificates already exist; also serves as client authentication	TLS termination at load balancers breaks the binding unless the certificate is forwarded securely; certificate lifecycle becomes part of OAuth operations. See the mTLS Guide.
Plain bearer	None: possession equals use	Universal support	Stolen tokens are replayable from anywhere until they expire or are revoked

FAPI 2.0 Security Profile: the high-assurance baseline

FAPI 2.0 closes the options OAuth leaves open and fixes values so implementations interoperate and can be tested.

Authorisation server requirements

Client types: confidential clients only; the password grant is rejected.
Client authentication: mutual TLS (RFC 8705) or private_key_jwt. Client assertions accept only the issuer identifier as a string in aud.
Pushed Authorisation Requests: PAR is mandatory, requests without it are rejected, and PAR calls must be client-authenticated. The returned request_uri must have expires_in below 600 seconds.
Flow: response_type=code only, PKCE with S256, redirect_uri required in the pushed request, http redirects forbidden except native app loopback.
Codes: single use, with a maximum lifetime of 60 seconds.
Tokens: only sender-constrained access tokens (mTLS or DPoP), with authorisation code binding to the DPoP key when DPoP is used.
Mix-up defence: return the iss parameter (RFC 9207).
Redirects carrying credentials: HTTP 303, not 307, so a browser does not re-post a user's password to the client.
Refresh tokens: avoid rotation except in extraordinary circumstances, because tokens are already sender-constrained and rotation causes availability failures; if rotation is used, provide a time-limited retry.

Client, resource server and cryptography requirements

Clients: send only client_id and request_uri to the authorisation endpoint, generate a fresh PKCE challenge for every request, check iss, and use only metadata from the discovery document whose issuer matches.
Resource servers: accept tokens only in the HTTP header, never in query parameters, and verify integrity, expiry, revocation and the sender constraint.
TLS: 1.2 or later, cipher suites per BCP 195.
Signing algorithms: PS256, ES256 or EdDSA with Ed25519; none is never used or accepted. RSA keys at least 2048 bits, elliptic curve keys at least 224 bits.
Key distribution: jwks_uri served over TLS only; avoid x5u and jku headers, which let a token point to its own verification key.

The profile sets no numeric access token lifetime, and only the authorisation code flow and CIBA have been formally analysed; client credentials is structurally supported but outside the analysis, which is relevant if you plan to apply FAPI to service-to-service traffic.

The FAPI 2.0 Attacker Model

The Attacker Model defines three security goals, authorisation (no attacker accesses resources other than their own), authentication (no attacker logs in as another user) and session integrity (no attacker forces a user into the attacker's session or resources), and the attackers the profile must withstand.

Attacker	Capability	Profile controls that answer it
A1 web attacker	Runs its own endpoints, takes part in flows as a normal user, lures users to links	PKCE, exact redirects, `iss` checks, single-use short-lived codes
A1a malicious authorisation server	A web attacker that also operates an AS in the ecosystem and replays honest AS messages	Issuer checks on metadata and responses, issuer-only `aud` in client assertions
A2 network attacker	Controls the network and can intercept, block and tamper	TLS 1.2+, sender-constrained tokens, signed client authentication
A3a reader of authorisation requests	Passively reads requests, for example from browser history or URL handlers	PAR keeps request content off the front channel; PKCE protects the code
A5 reader of resource requests	Reads requests after the RS processes them, for example in TLS-intercepting proxy logs	DPoP or mTLS binding makes logged tokens unusable without the key

The model excludes compromised browsers or operating systems, remote code execution on the authorisation server, exposed databases, weak random number generation and implementation errors.

FAPI certification

The OpenID Foundation provides a free, open conformance suite. Implementers run the tests themselves and submit results through the self-certification process, after which a product or deployment may use the "OpenID Certified" mark; a fee schedule applies to certification, and the Foundation is building a network of authorised auditors. Certification shows a product passed the tests at a point in time, not that your deployment is configured the same way, so rerun the suite against your own tenant before go-live.

GNAP: what is different and when it fits

GNAP (Grant Negotiation and Authorization Protocol) was designed by the IETF to cover OAuth's use cases without inheriting its structure. A client instance sends a JSON request to a single grant endpoint, and the response can carry several labelled tokens and subject information together.

Structured access, not scope strings: the access array holds objects with type, actions, locations and datatypes, so a request can say "read and write invoices at this API location" rather than relying on an opaque scope name.
Key-bound by default: tokens are bound to the client instance's key unless the client explicitly sets the bearer flag. Key proofing methods include HTTP Message Signatures (httpsig), mutual TLS, detached JWS and attached JWS.
Interaction is negotiated: the client lists the start modes it supports (redirect, application URI or user code) and finish methods (redirect, push callback or polling); an interaction hash protects the return leg.
Continuation: a key-bound continuation token lets the client poll, continue after user interaction, modify or revoke the grant.
Resource servers: RFC 9767 defines discovery at /.well-known/gnap-as-rs, token introspection, resource set registration and how an RS derives a downstream token to call another RS, which is directly relevant to chains of services and agents.

The trade-off is ecosystem: OAuth tooling is everywhere, GNAP support is limited and no regulator mandates it. Outside greenfield designs you control end to end, OAuth 2.1 with DPoP and PAR reaches much of the same posture with mainstream tooling.

Choosing between OAuth 2.1, FAPI 2.0 and GNAP

Situation	Recommended baseline	Reason
Internal APIs and SaaS integrations, mixed client estate	OAuth 2.1 rules, enforced through RFC 9700, with DPoP for high-value clients	Broad support; removes the most exploited patterns without re-platforming
Payments, account data, health records, regulated open finance	FAPI 2.0 Security Profile, plus Message Signing where non-repudiation is required	Fixed parameters, formal analysis and testable conformance
Public clients on user devices: SPAs, CLIs, desktop agents	OAuth 2.1 with PKCE S256, DPoP, refresh token rotation, short access token lifetimes	No client secret is possible, so binding and rotation carry the load
MCP servers and AI agent tool access	MCP authorisation specification on OAuth 2.1, with resource indicators and audience checks	Interoperability with MCP clients; token passthrough is explicitly forbidden
Greenfield ecosystem you control end to end, needing multiple key-bound tokens per grant	Evaluate GNAP (RFC 9635, RFC 9767)	Cleaner delegation model, at the cost of tooling and skills

Small organisations: usually consume an identity provider rather than run an authorisation server. The work is configuration: disable legacy grants, enforce PKCE and exact redirects, enable DPoP or certificate binding where offered, and shorten token lifetimes. Large organisations and platform providers: run several authorisation servers and gateways, so the effort is one policy for every issuer and resource server, conformance testing in CI and a legacy client migration plan.

OAuth 2.1 for MCP and AI agents

The MCP authorisation specification (versions 2025-06-18 and 2025-11-25) makes an MCP server an OAuth 2.1 resource server and references draft-ietf-oauth-v2-1-13. See the MCP Security Guide for the wider MCP threat picture.

Audience binding: clients must send the RFC 8707 resource parameter with the MCP server's canonical URI in both the authorisation and token requests, and servers must reject tokens not issued for them.
No token passthrough: an MCP server that calls upstream APIs must obtain its own token for them and must not forward the token it received. Delegation across hops belongs to token exchange; see the OAuth Token Exchange and Delegation Guide.
PKCE verification: in the 2025-11-25 version clients must use S256 and must refuse to proceed if code_challenge_methods_supported is absent from the server metadata.
Scope negotiation: clients request the scopes named in the WWW-Authenticate challenge, falling back to scopes_supported. At runtime a server returns HTTP 403 with error="insufficient_scope" and the required scopes, and the client performs a step-up authorisation with retry limits.
Client registration: the 2025-11-25 version prefers pre-registration, then Client ID Metadata Documents (an HTTPS URL as client_id), with Dynamic Client Registration demoted to MAY. Authorisation servers fetching those documents must guard against server-side request forgery and display the redirect hostname, because localhost redirects allow client impersonation.

For agents acting for users, combine these rules with the patterns in the AI Agent Authorisation Guide.

How to implement: a phased migration

Inventory clients and grants. Export every client with its grant types, client type, authentication method, redirect URIs and token lifetimes; flag implicit, password and wildcard-redirect clients.
Set the target profile. Write one policy: OAuth 2.1 plus RFC 9700 for the general estate, FAPI 2.0 for named high-value APIs. Record exceptions with owners and end dates.
Enforce PKCE and exact redirects first. These are low-risk changes for compliant clients. Enable per client in pilot rings and watch authorisation errors for a week before tightening globally.
Retire implicit and password grants. Give owners a migration path (code with PKCE, client credentials for machines), then disable the grants client by client.
Introduce sender constraint. Start with new clients and a single resource server that validates DPoP or mTLS. Accept both bound and bearer tokens during transition, log which is presented, then switch the resource server to reject bearer tokens for bound clients.
Add PAR and stronger client authentication for FAPI-scoped APIs: private_key_jwt or mTLS in place of shared client secrets, PAR mandatory, 60-second codes.
Tighten tokens. Audience-restrict access tokens, shorten lifetimes, rotate or bind refresh tokens for public clients, and verify that revocation reaches resource servers through introspection or short lifetimes. See the Token and Session Security Guide.
Test conformance, with rollback ready. Keep each enforcement step behind a per-client setting and agree the error rate that triggers a revert. Run the OpenID conformance suite for FAPI scope and negative tests in CI (missing PKCE, token in query, DPoP proof reuse).

Detection and measurement

Authorisation server logs: grant type per token issued, PKCE presence and method, PAR usage, redirect mismatches, client authentication method, and refresh token reuse (a reused rotated refresh token signals theft and should revoke the family).
Resource server logs: token type presented (Bearer, DPoP), DPoP proof failures (invalid_dpop_proof), audience mismatches, and tokens arriving in query strings. Alert on token use from new networks or anonymising infrastructure, the pattern of ATT&CK T1528 and T1550.001.

Metric	Target direction
Percentage of clients using implicit or password grants	Zero, with dated exceptions only
Percentage of authorisation code flows with PKCE S256	100%
Percentage of access tokens for high-value APIs that are sender-constrained	Rising to 100%
Median access token lifetime by client class	Falling; minutes rather than hours for public clients
Conformance suite pass rate for FAPI-scoped deployments	100% on every release

Common failure patterns

Calling the draft an RFC in policy. Cite RFC 9700 and the specific draft version, or FAPI 2.0 Final, in contracts and audit criteria.
Long-lived bearer refresh tokens held by integrations. In the Salesloft Drift breach, OAuth access and refresh tokens taken from the vendor's environment were used from 8 to 18 August 2025 to export data from many Salesforce tenants until all Drift tokens were revoked on 20 August. Sender-constrained tokens and tighter lifetimes reduce what a stolen token store is worth.
Binding at the AS but not checking at the RS. Issuing DPoP tokens while resource servers still accept them as Bearer gives no protection; RFC 9449 requires the RS to reject that downgrade.
Rotation without a retry window. Strict refresh token rotation on unreliable networks logs users and agents out and pushes teams to disable it; FAPI 2.0 advises a time-limited retry option.
Token passthrough in agent chains. A tool server forwarding the user's token to downstream APIs creates a confused deputy; the MCP specification forbids it for that reason.

Framework mapping

Framework	Reference	Relevance
OWASP ASVS 5.0	V10.3.5, V10.4.1, V10.4.5, V10.4.10, V10.4.13, V10.4.14	Sender-constrained tokens at the RS, exact redirect matching, refresh token replay for public clients, authenticated back-channel requests, code with PAR, AS issuing only sender-constrained tokens
NIST SP 800-53 Rev. 5	IA-2, IA-5, IA-8, AC-3, SC-23	Authentication of users and non-organisational users, authenticator management, access enforcement, session authenticity
NIST CSF 2.0	PR.AA-01, PR.AA-03, PR.AA-05, PR.DS-02	Identity and credential management, authentication, least privilege authorisations, data in transit
MITRE ATT&CK v20	T1528, T1550.001, T1557	Token theft, token reuse, adversary in the middle
MITRE D3FEND	D3-TB Token Binding	The countermeasure class that DPoP and mTLS implement
ISO/IEC 27001:2022 Annex A	5.15 Access control, 5.17 Authentication information, 8.5 Secure authentication	Policy and technical control homes for authorisation protocol choices

Practitioner checklist

Record the OAuth 2.1 draft version you align to (currently -16) and cite RFC 9700 as the normative baseline.
Disable implicit and password grants on every authorisation server, with dated exceptions.
Enforce PKCE with S256 and exact redirect URI matching for all clients.
Keep tokens out of URLs: header only at every resource server and gateway.
Issue sender-constrained tokens (DPoP or mTLS) for high-value APIs and make resource servers reject the bearer downgrade.
Apply FAPI 2.0 in full to payment, account data and other high-value APIs: PAR, confidential clients, private_key_jwt or mTLS, 60-second codes, PS256, ES256 or EdDSA.
Audience-restrict tokens with resource indicators, and forbid token passthrough in service and agent chains.
Rotate or bind refresh tokens for public clients and alert on refresh token reuse.
Run the OpenID conformance suite and negative OAuth tests in CI on every release.

OAuth 2.1, GNAP and FAPI Guide: Modern Authorisation Protocols Explained