Skip to main content
Agent Identity

IETF · 31 October 2026

The OAuth 2.1 Authorization Framework

draft-ietf-oauth-v2-1-17

D. Hardt, A. Parecki (ed.), T. Lodderstedt

WG draftDraft — expect changeAuthorizationFoundationField guide

The OAuth 2.1 Authorization Framework (draft-ietf-oauth-v2-1-17) is WG draft, 31 October 2026. 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

How OAuth 2.1 works

Animated sequence · OAuth 2.1

OAuth 2.1 — How does a client get an access token without putting it in the URL?

Authorization code + PKCE, hop by hop

Four roles: resource owner, client, authorization server, resource server. The client discovers how to authorize, proves it started the flow with PKCE, collects a code on the front channel, redeems it on the back channel, and calls the API with an Authorization header. No implicit grant. Optional hops (PRM, AS metadata, PAR, introspection) are labeled — not omitted.

RO (user)sends
Client (agent)gets
Authorization server
Resource server

Now · 1/16· Discover· OAuth 2.1 rolesYou are here

RO (user)→Client (agent)·Asks the client (agent/host) to call an API that needs a pass

The resource owner (RO) asks the OAuth client to reach a resource server (RS). The authorization server (AS) has not been called yet.

Why The resource owner is not the client. Collapsing this into 'the agent logs in' hides who consents and who later holds the token.

Someone at the desk asks a messenger to fetch a pass for a locked room.

  • resource owner from the spec
  • client from the spec
  • authorization server from the spec
  • resource server from the spec

Solid = from the spec

Step 1 of 16: user to agent. Asks the client (agent/host) to call an API that needs a pass OAuth 2.1 roles
Speed
ShareLinkedInX

OAuth 2.1 is still draft-ietf-oauth-v2-1 (not an RFC). MCP HTTP is this shape with RFC 9728 discovery on the front. PAR, PRM, and AS metadata are optional only when the client is already configured — they are not secret steps.

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 1 November 2026 (draft-ietf-oauth-v2-1-17) — not an RFC. It is 2.0 with the unsafe bits removed, not a new protocol. Side-by-side.

Hop list

Sequence above; this list is the same hops for reading and search. Each row is one message.

  1. 1

    RO (user)→Client (agent)OAuth 2.1 rolesAsks the client (agent/host) to call an API that needs a pass

  2. 2

    Client (agent)→Resource serverRFC 6750Calls the API with no Authorization header yet

  3. 3

    Resource server→Client (agent)RFC 9728401 + WWW-Authenticate pointing at resource_metadata

  4. 4

    Client (agent)→Resource serverRFC 9728GET protected resource metadata (PRM)

  5. 5

    Client (agent)→Authorization serverRFC 8414GET authorization-server metadata

  6. 6

    Client (agent)→Client (agent)RFC 7636Generates a PKCE code_verifier and S256 code_challenge

  7. 7

    Client (agent)→Authorization serverRFC 9126POST pushed authorization request (PAR) with the rich parameters

  8. 8

    Authorization server→Client (agent)RFC 9126Returns request_uri (one-time, short-lived)

  9. 9

    Client (agent)→Authorization serverOAuth 2.1Redirects the browser to the authorization endpoint: response_type=code, code_challenge, …

  10. 10

    RO (user)→Authorization serverOAuth 2.1Authenticates at the authorization server

  11. 11

    RO (user)→Authorization serverOAuth 2.1Consents to this client for this resource and scope

  12. 12

    Authorization server→Client (agent)OAuth 2.1Redirects back with an authorization code — never an access token in the URL

  13. 13

    Client (agent)→Authorization serverRFC 7636POSTs the token endpoint: code + code_verifier (and client auth if confidential)

  14. 14

    Authorization server→Client (agent)RFC 6750Returns an access token (and a refresh token if any)

  15. 15

    Client (agent)→Resource serverRFC 6750Calls the RS with Authorization header, audience-restricted

  16. 16

    Resource server→Client (agent)RFC 9068Validates the token (JWT RFC 9068 locally, or introspection) and responds

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-17 (31 October 2026) consolidates 6749, 6750, RFC 8252, RFC 7636, RFC 9700, and RFC 10017, 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-17 fills the browser-based applications section with the normative requirements from RFC 10017 and cites that RFC. The draft-16 TODO that pointed at draft-ietf-oauth-browser-based-apps-27 is gone. RFC 10017 remains the stable BCP citation.

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-17 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 are in draft-17 §1.8. The draft header now lists Obsoletes: 6749, 6750 (if approved).

  • 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 -17 + 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. Datatracker HTML for draft-17 is dated 31 October 2026 and expires 4 May 2027. 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 apps and RFC 10017

    Draft-17 now includes the normative browser-app requirements from RFC 10017. XSS on a chat UI still steals the agent's tokens; the RFC remains the BCP to cite.

08

Stability — what you can ship

draft-ietf-oauth-v2-1-17, 31 October 2026, expires 4 May 2027, OAuth WG, intended standards track. Authors: D. Hardt, A. Parecki (ed.), T. Lodderstedt. HTML: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-17. 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 1 November 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 draft-17 and RFC 9700, not against memory of 2.0. Draft-17 (31 October 2026, expires 4 May 2027) fills the browser-based applications section with the normative requirements from RFC 10017 and cites that RFC.

Related

Specs

Deployment patterns

Flows

Compare

Primary sources