Skip to content
Agent Identity

IETF · 3 September 2026

The OAuth 2.1 Authorization Framework

draft-ietf-oauth-v2-1-16

D. Hardt, A. Parecki, T. Lodderstedt

WG draftDraft — expect changeAuthorizationFoundationField guide

This is the security baseline MCP, FAPI 2.0 thinking, and most 'agent as OAuth client' designs now assume: PKCE always, no implicit, no password grant, no tokens in URLs. If your agent SDK still does implicit or stores refresh tokens unbound in local storage, it is not 2.1-shaped.

At a glance

Problem
OAuth 2.0 plus a decade of extensions and deprecations is too fragmented to implement safely from RFC 6749 alone. OAuth 2.1 consolidates the core framework with the security practices that actually survived contact with the internet.
Identity / authn / authz
Same layer as OAuth 2.0: delegated authorization. It still is not an identity protocol. OpenID Connect remains the identity layer that rides on top.

Actors

  • Resource owner
  • Client (confidential or public)
  • Authorization server
  • Resource server

In one board · OAuth 2.1 vs 2.0

What got banned

2.0 allowed

response_type=token put the access token in the URL fragment. The front channel was the mint.

Bearer in the wild

2.1 omits

Omitted, following RFC 9700. Do not issue access tokens in the front channel.

Authorization header

A pass taped to the address bar is a photocopy the whole café can see — logs, Referer, shoulder surfers.

  • Authorization code + PKCE (S256) is the interactive default. Plain PKCE is gone.
  • Redirect URIs match as exact strings. Bearer is still a photocopy unless you add DPoP or mTLS.

OAuth 2.1 is still a working-group draft as of September 2026 (draft-ietf-oauth-v2-1-16) — not an RFC. It is 2.0 with the unsafe bits removed, not a new protocol. Side-by-side.

01

The gap for agents

OAuth 2.1 exists because implementing RFC 6749 from the 2012 text is how you get implicit flow, password grants, tokens in URLs, and loose redirect matching. draft-ietf-oauth-v2-1-16 (3 September 2026) consolidates 6749, 6750, RFC 8252, RFC 7636, RFC 9700, and the browser-based apps BCP, and omits what RFC 9700 found unsafe.

For agents, 'speak OAuth 2.1' is the security baseline MCP, FAPI-shaped thinking, and most host-as-client designs now assume: authorization code + PKCE always, no implicit, no password grant, exact redirects, no tokens in URIs, refresh tokens for public clients sender-constrained or rotated. It still does not give the agent a portable identity.

02

Actors and trust boundaries

Same four roles as 6749. Client types are simplified: confidential clients have credentials with the AS; public clients do not. Browser-based apps and many local agents are public (or should use a BFF). The user-agent remains untrusted. Agent hosts that hold refresh tokens are a new high-value target 2.1 addresses with rotation / sender constraint, not with a new role.

03

Mechanics

Three grant types: authorization code (with PKCE; S256 only; plain prohibited), refresh token, client credentials. Implicit (response_type=token) and resource owner password credentials are omitted. Authorization code at the token endpoint no longer includes redirect_uri — PKCE replaced that defense. Mixed-mode ASes MUST still accept redirect_uri from old 2.0 clients.

Redirect URIs: exact string match (RFC 3986 simple string comparison), with a localhost port exception for native apps. If multiple redirect URIs are registered, the authorization request MUST include redirect_uri; if only one is registered, it is optional.

PKCE is required for the authorization code grant, including confidential clients, because code injection hits them too. Refresh tokens remain opaque to the client and are never sent to resource servers. Public-client refresh tokens must be sender-constrained or one-time-use (rotated), following RFC 9700. Sender-constrained access tokens (DPoP, mTLS) are discussed as additional authentication when presenting a token; they are not mandatory for all 2.1 deployments (FAPI 2.0 does mandate them).

Draft-16 §7.2 still has 'TODO: Bring in the normative text of the browser-based apps BCP when it is finalized.' RFC 10017 published in August 2026; the 2.1 draft still cites draft-ietf-oauth-browser-based-apps-27 (6 July 2026). Implement RFC 10017 for SPAs while that TODO remains.

code_challenge / code_verifier (S256)from spec
Quoted: PKCE is the default authorization-code exchange. plain is removed.
grant_type=authorization_code | refresh_token | client_credentialsfrom spec
Quoted 2.1 grant set. Extension grants (token exchange, CIBA, JWT bearer) still exist as other specs.
redirect_uri on token requestfrom spec
Quoted removal in 2.1. 2.0 servers that still require it will break a pure-2.1 client — detect mixed mode.
token_type=Bearerfrom spec
Still the default presentation. URI placement omitted. DPoP uses token_type=DPoP when that RFC applies.

04

Step-by-step flows

Flow 1 of 2

Authorization code + PKCE (interactive agent consent)

  1. 1

    Client generates a fresh code_verifier and S256 code_challenge per authorization request.

  2. 2

    Authorization request: response_type=code, client_id, scope, resource (RFC 8707, required by MCP), code_challenge, code_challenge_method=S256, exact redirect_uri if multiple are registered.

  3. 3

    Prefer PAR (RFC 9126) if the request is large or sensitive. User authenticates (OIDC) and consents.

  4. 4

    Token request: grant_type=authorization_code, code, code_verifier, client authentication if confidential. No redirect_uri on a 2.1-only AS.

  5. 5

    Store refresh tokens bound to this client; rotate or sender-constrain them if the agent is a public client. Call the RS with Authorization: Bearer (or DPoP).

Flow 2 of 2

Client credentials (autonomous agent)

  1. 1

    Client authenticates to the token endpoint (secret, private_key_jwt, mTLS, or SPIFFE client auth).

  2. 2

    grant_type=client_credentials, optional scope and resource.

  3. 3

    RS sees a token about the client, not about a user. Do not pretend otherwise.

05

Identity vs authentication vs authorization

Still delegated authorization, not identity. Section 1 of draft-16 is explicit: OAuth is not an authentication protocol; use OpenID Connect if you need to authenticate users. An access token presented to a proprietary 'userinfo-ish' API is not OIDC.

Client authentication is how the AS knows which application is at the token endpoint. Resource-request authentication of the caller is Bearer or a sender-constraint proof.

06

How it composes

  • OAuth 2.0

    2.1 replaces and obsoletes 6749/6750 as a specification; the internet still runs 2.0. Compatibility notes in draft-16 §10.

  • OAuth Security BCP

    2.1 is RFC 9700 folded into the core. If 2.1 is still a draft in your compliance matrix, implement RFC 9700 on 2.0 today.

  • PKCE

    Folded in; S256 only.

  • OpenID Connect Core

    Still the identity layer. ID Token response types remain OIDC's concern.

  • MCP authorization

    MCP 2026-07-28 requires OAuth 2.1 but still cites draft-13. Implement current -16 + RFC 9700, and obey MCP MUST/SHOULD (resource parameter, PRM, CIMD).

  • AAuth

    Different protocol for open-world signed clients. Use 2.1 where the RS is OAuth; evaluate AAuth where client_id portals will not scale.

  • FAPI 2.0

    High-security profile on top: PAR mandatory, confidential clients only, sender-constrained tokens, 60-second codes. 2.1 alone is not FAPI.

07

What bites agent implementers

  • Not an RFC yet

    WG Internet-Draft, milestone to submit to IESG December 2026. The OAuth WG document list still showed -15 (2 March 2026) in some views while datatracker HTML for -16 (3 September 2026) exists. Cite the revision you implemented.

  • Mix-up across many ASes

    Agents talk to many MCP servers / SaaS ASes. Implement RFC 9207 iss and exact issuer metadata checks; 2.1 assumes you read RFC 9700.

  • Public-client refresh tokens

    A CLI agent that stores an unbound refresh token in a homedir file is the 2.1 public-client problem. Rotate or sender-constrain, or use a confidential BFF.

  • Browser TODO vs RFC 10017

    Do not wait for 2.1 to finish importing browser-app text. RFC 10017 is published; XSS on a chat UI steals the agent's tokens.

08

Stability — what you can ship

draft-ietf-oauth-v2-1-16, 3 September 2026, expires 7 March 2027, OAuth WG, intended standards track. Authors: D. Hardt, A. Parecki, T. Lodderstedt. HTML: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-16. Latest tracker: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/. You can ship the 2.1 shape today by implementing RFC 9700 + PKCE on 2.0; you cannot yet put 'OAuth 2.1 RFC' in a contract.

Catalog claims (short form)

code_challenge / code_verifier
PKCE is the default authorization-code exchange. The plain method is removed.
redirect_uri at token endpoint
Removed in 2.1 because PKCE already stops code injection. Mixed 2.0/2.1 servers may still require it for old clients.

Implementer notes

Not an RFC as of September 2026. OAuth WG milestone is to submit it to the IESG in December 2026. MCP's 2026-07-28 authorization spec still cites draft-ietf-oauth-v2-1-13; implement against the current draft-16 text and RFC 9700, not against memory of 2.0. Draft-16's browser-apps section still had a TODO to import RFC 10017 once finalized — RFC 10017 has since been published.

Relationship to others

Primary sources