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 September 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 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.
| Aspect | OAuth 2.0 (RFC 6749 / 6750) | OAuth 2.1 (draft-ietf-oauth-v2-1-16) |
|---|---|---|
| Status | Internet Standard-track RFCs, universally deployed. | Working Group Internet-Draft (rev 16, Sep 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. |
Takeaway
For agent implementers, 'speak OAuth 2.1' means: authorization code + PKCE always, no implicit, no password grant, exact redirects, audience-restricted tokens, no tokens in URLs. MCP already requires this shape even while citing an older 2.1 draft.
Field notes
Draft-16 vs what datatracker lists
HTML of draft-ietf-oauth-v2-1-16 is dated 3 September 2026 and expires 7 March 2027. Some OAuth WG index views still showed -15 (2 March 2026) as the WG document row. Cite the revision you implemented. MCP 2026-07-28 still cites draft-13; implement token handling against -16 and RFC 9700.
Browser apps TODO
Draft-16 still has a TODO to import the browser-based apps BCP and cites draft-ietf-oauth-browser-based-apps-27. RFC 10017 published in August 2026. Chat UIs that broker agent OAuth in the browser should follow the RFC, not wait for 2.1 to finish copying it.