OAuth 2.1

What it is

OAuth 2.1 is not a new protocol but a cleanup: it folds OAuth 2.0, PKCE, and the OAuth Security Best Current Practice into one document and removes the parts that proved unsafe. The goal is that a developer who follows OAuth 2.1 gets a secure result by default, without having to read a dozen RFCs and errata.

What changes from OAuth 2.0

• PKCE is required for all authorization code flows, not just public clients.
• The implicit grant is removed. Tokens are no longer returned in the front channel.
• The resource owner password credentials grant is removed.
• Exact redirect URI matching is mandated.
• Refresh token handling is tightened, with rotation or sender-constraining for public clients.

The full list, from section 10 of draft-17, adds five changes that catch implementers out:

• No bearer tokens in query strings. Only the Authorization header (or form body) is allowed, following RFC 9700 section 4.3.2.
• The PKCE plain method is removed. Only S256 remains in practice.
• The token request no longer carries redirect_uri. PKCE does the job the parameter was meant to do.
• Authorization servers must accept client credentials in the request body, not only via HTTP Basic.
• Browser-based apps get additional refresh token lifetime limits from RFC 10017, OAuth 2.0 for Browser-Based Applications, published as a Best Current Practice in August 2026.

The draft is explicit about compatibility: an OAuth 2.0 client that skips PKCE, relies on redirect URI pattern matching, or uses the implicit or password grants "will not interoperate" with an authorization server that enforces OAuth 2.1 for that client.

What it consolidates

Draft-17 lists the documents it folds in: OAuth 2.0 (RFC 6749), Bearer Token Usage (RFC 6750), OAuth 2.0 for Native Apps (RFC 8252), PKCE (RFC 7636), the OAuth 2.0 Security Best Current Practice (RFC 9700, January 2025) and OAuth 2.0 for Browser-Based Applications (RFC 10017). If approved it obsoletes RFC 6749 and RFC 6750. Extensions such as token exchange, DPoP, PAR and resource indicators stay separate RFCs that OAuth 2.1 deployments add as needed.

How it works

The model is the same as OAuth 2.0: clients obtain scoped access tokens from an authorization server. In practice OAuth 2.1 means: use the authorization code flow with PKCE for anything with a user, the client credentials grant for machine-to-machine, and the device authorization grant for input-constrained devices.

Status

OAuth 2.1 is an active IETF draft. Revision -17 is dated 31 October 2026, and its datatracker state, read 5 November 2026, is WG Document in the OAuth Working Group: adopted, not yet through working-group last call. The OAuth WG milestones list "Submit OAuth 2.1 Authorization Framework to IESG" for December 2026. The editors are Dick Hardt (Hellō), Aaron Parecki (Okta) and Torsten Lodderstedt (SPRIND).

Most modern identity platforms already implement its recommendations, so adopting it today is mostly about avoiding the removed flows rather than waiting for a final RFC.

Why it matters for AI agents

The Model Context Protocol requires its authorization servers to "implement OAuth 2.1", and its revision 2026-07-28 cites draft-13 of this document while the draft itself has moved to -17. In practice that makes OAuth 2.1 the baseline for every remote MCP server: authorization code with PKCE for agents acting for a user, client credentials for agents acting as themselves, and short-lived tokens with rotated refresh tokens for public clients such as desktop agents and IDE plugins. SWI's Agent Identity Standards Map 2026 tracks the draft as one of two moving dependencies under MCP. The OAuth 2.1 rules are necessary but not sufficient for agents; the securing AI agent identities guide covers audience binding, delegation and revocation on top.

How to check an implementation

1. Send an authorization request with response_type=token. An OAuth 2.1 server rejects it.
2. Send a code request without code_challenge. It should fail for every client type.
3. Register https://app.example.com/callback and request https://app.example.com/callback/extra. Exact matching rejects it.
4. Send an access token as ?access_token= in a resource request. It should be refused.
5. For a public client, redeem a refresh token twice. Rotation means the second attempt fails, and ideally revokes the token family.

Pitfalls

• Legacy apps using the implicit or password grants need migration before they can claim OAuth 2.1 compliance.
• "OAuth 2.1 support" from a vendor usually means PKCE-by-default and dropped legacy grants; confirm the specifics.

How it works, message by message

The OAuth message-flow walkthrough shows each OAuth 2.1 message next to its OAuth 2.0 equivalent, with section numbers from draft-17, so you can see exactly where PKCE, exact redirect matching, the removed grants and the dropped redirect_uri in the code exchange change the wire format.

Related

OAuth 2.0, OpenID Connect, MCP authorization, ID-JAG and Cross App Access, and the guide OAuth vs OIDC. Glossary: PKCE, refresh token, bearer token.

Who wrote it

The consolidation is co-edited by Aaron Parecki, and it folds in the OAuth 2.0 Security Best Current Practice edited by Torsten Lodderstedt with Daniel Fett. More in the experts directory.