2.0 allowed
response_type=token put the access token in the URL fragment. The front channel was the mint.
Bearer in the wild
Compare
OAuth 2.0 vs OAuth 2.1
2.1 is not a new protocol. It is 2.0 with the unsafe bits removed and PKCE folded into the core. Still a WG draft as of 1 November 2026.
In one board · OAuth 2.1 vs 2.0
What got banned
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.
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
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.
| Aspect | OAuth 2.0 (RFC 6749 / 6750) | OAuth 2.1 (draft-ietf-oauth-v2-1-17) |
|---|---|---|
| Status | Internet Standard-track RFCs, universally deployed. | Working Group Internet-Draft (rev 17, 31 October 2026). Milestone: submit to IESG Dec 2026. Not an RFC yet. |
| Authorization Code | Defined. PKCE is a later extension (RFC 7636), originally for public clients. | Authorization Code with PKCE is the default interactive grant. PKCE plain method removed. |
| Implicit grant | Defined (response_type=token). | Omitted, following RFC 9700. Do not issue access tokens in the front channel. |
| Resource Owner Password Credentials | Defined. | Omitted. The client must not collect passwords. |
| Redirect URIs | Matching rules were loose in practice. | Exact string matching (RFC 9700 §4.1.3). |
| Bearer tokens in URIs | RFC 6750 allowed query-string tokens. | Omitted. Tokens stay in the Authorization header. |
| Public-client refresh tokens | Often long-lived bearer secrets. | Must be sender-constrained or one-time-use (rotated). |
| redirect_uri on token request | Required if it was sent on the authorization request. | Removed; PKCE addresses code injection. Mixed-mode ASes may still require it for old clients. |
| Sender constraint | Optional. Bearer tokens are the 2012 default. DPoP/mTLS arrived later. | Still not mandatory for all 2.1 ASes (FAPI 2.0 does mandate PoP). Public-client refresh tokens must be sender-constrained or rotated. Access-token PoP is discussed, not universally required. |
| What an agent should implement | Only as constrained by RFC 9700. Do not implement implicit or password grants from the 6749 text. | Authorization code + PKCE S256, exact redirects, no tokens in URLs, resource indicators, iss checks. MCP already requires this shape while citing an older 2.1 draft. |
| Identity | None. Use OpenID Connect. | Still none. Use OpenID Connect. ID Token response types remain OIDC's concern. |
Remember
Speak OAuth 2.1: authorization code + PKCE, never implicit, never password, never a token in the URL. Exact redirects. Audience on the pass. MCP already demands this shape — even while citing an older draft.
Field notes
Draft-17
HTML of draft-ietf-oauth-v2-1-17 is dated 31 October 2026 and expires 4 May 2027. Cite the revision you implemented. MCP 2026-07-28 still cites draft-13; implement token handling against -17 and RFC 9700.
Browser apps and RFC 10017
Draft-17 fills the browser-based applications section with the normative requirements from RFC 10017 and cites the RFC. Chat UIs that broker agent OAuth in the browser should still follow RFC 10017; XSS on that page steals the agent's tokens.