OAuth 2.1 vs OAuth 2.0: What Changed and How to Migrate

OAuth 2.0 was never a single document. It was RFC 6749 from 2012, the bearer token rules in RFC 6750, and then a decade of separate best-practice notes patching holes that the original framework left open. If you learned OAuth from a tutorial written in 2015, you almost certainly learned patterns that the community has since quietly retired. OAuth 2.1 is the cleanup: one specification that keeps what works, deletes what proved dangerous, and folds the security guidance directly into the normative text.

I have shipped enough integrations to know the gap between what the old spec allowed and what you should actually do in production. OAuth 2.1 closes that gap by making the safe path the only path. This post walks through exactly what changed, shows an accurate Authorization Code plus PKCE exchange, and gives you a migration order you can follow without breaking live clients.

OAuth 2.1 is a consolidation, not a reinvention

The draft is explicit that it replaces and obsoletes RFC 6749 and RFC 6750, consolidating the information from those documents and the security best current practice into a single Standards Track specification while removing features found to be insecure. There is no new token format, no new core grant, and no new endpoint. If you already run the authorization code flow correctly today, most of your system is already OAuth 2.1 compliant. The work is in what you must stop doing.

PKCE is now mandatory for every client

Under OAuth 2.0, Proof Key for Code Exchange was an add-on, recommended mainly for mobile and single-page apps that could not keep a secret. OAuth 2.1 promotes it to a baseline requirement: PKCE is required for all clients using the authorization code flow, confidential web servers included. The client generates a random verifier, sends only its hash as a challenge on the authorization request, and reveals the verifier when it redeems the code. An attacker who intercepts the code cannot exchange it without the original verifier.

# 1. Client generates a PKCE pair (S256)
code_verifier  = base64url( random(32 bytes) )
code_challenge = base64url( SHA256(code_verifier) )

# 2. Authorization request — a browser redirect that returns a code, never a token
GET /authorize?response_type=code
  &client_id=s6BhdRkqt3
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
  &scope=read%20write
  &state=xyz
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256 HTTP/1.1
Host: as.example.com

# 3. Authorization server redirects back with a short-lived, one-time code
HTTP/1.1 302 Found
Location: https://app.example.com/callback?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

# 4. Token request — the client proves it owns the verifier behind that challenge
POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
&client_id=s6BhdRkqt3
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

Two grant types are gone

OAuth 2.1 omits two flows that RFC 6749 defined. Both leaked tokens or credentials in ways no configuration could fully fix, so instead of documenting workarounds the spec simply removes them.

• The implicit grant, where the authorization server returned an access token directly in the redirect fragment, is omitted. Tokens in the URL end up in browser history, logs, and referrer headers. Browser apps now use the authorization code flow with PKCE instead.
• The resource owner password credentials grant, where the app collected the user's actual username and password and sent them to the token endpoint, is omitted. It defeats the entire point of delegated authorization and blocks federation and multi-factor prompts.

If you have either flow in production, that is the migration that carries real risk, because it changes how clients obtain tokens. Everything else in OAuth 2.1 is mostly tightening rules you were probably already close to following.

Tokens and redirects get stricter rules

Three smaller but load-bearing changes harden the parts of OAuth that attackers target most.

• Bearer tokens must not travel in a URL query string. RFC 6750 permitted a query parameter; OAuth 2.1 removes that option, so access tokens live only in the Authorization header or a form-encoded request body where they stay out of logs and history.
• Redirect URIs must be compared using exact string matching. The old habit of allowing a prefix or wildcard match is out, because it opened the door to open-redirect and token-theft attacks. Register every callback URL in full.
• Refresh tokens for public clients must be sender-constrained or one-time use. In practice that means rotation: each refresh returns a new refresh token and invalidates the old one, so a stolen refresh token stops working the moment the legitimate client uses the next one.

OAuth 2.0 vs OAuth 2.1 at a glance

Why MCP chose OAuth 2.1

The reason OAuth 2.1 suddenly matters to a lot of developers is the Model Context Protocol. MCP is how AI clients connect to external tools and data servers, and its authorization spec is built directly on OAuth 2.1. The MCP specification states that authorization servers must implement OAuth 2.1 with appropriate security measures for both confidential and public clients, and that MCP clients must implement PKCE according to OAuth 2.1. It pins the exact reference: draft-ietf-oauth-v2-1-13.

In MCP terms, a protected MCP server acts as an OAuth 2.1 resource server, the MCP client is an OAuth 2.1 client, and access tokens travel only in the Authorization header, never in a query string. MCP also layers on resource indicators from RFC 8707 so a token is bound to the specific server it was issued for, and it requires refresh token rotation for public clients. If you build an MCP server, you are implementing OAuth 2.1 whether you set out to or not.

How I would migrate

You do not need a big-bang rewrite. Migrate in an order that removes the riskiest patterns first and leaves the compatible tightening for last.

1. Add PKCE to every authorization code client, including confidential server-side apps. It is backward compatible with servers that already support it, so you can roll it out before anything else changes.
2. Retire the implicit and password grants. Move browser and mobile apps to authorization code with PKCE, and move machine-to-machine clients to the client credentials grant.
3. Stop reading bearer tokens from query strings and reject them there. Accept access tokens only from the Authorization header or a form-encoded body.
4. Register exact redirect URIs and turn on refresh token rotation for public clients, watching your logs for callbacks that relied on loose matching.

Do these four steps in order and you land on OAuth 2.1 without a flag day. The payoff is a smaller attack surface, one authoritative spec instead of a scavenger hunt across RFCs, and a token setup that is already compatible with MCP and the wave of AI tooling built on it.