OAuth 2.1 explained — what changed, what it replaces, when to use it

What got removed

OAuth 2.1 removes two grants that produced more incidents than value:

• Implicit Flow — Returned the access token directly in the URL fragment. Vulnerable to token leakage via browser history, referer headers, and analytics. Replaced by Authorization Code + PKCE, which is just as fast for SPAs and dramatically safer.
• Resource Owner Password Credentials (ROPC) — Client asks the user for their username + password, then exchanges them for a token. Defeats the entire purpose of OAuth (third-party auth without sharing the password). Was originally allowed only as a migration aid for legacy systems.

What got mandated

OAuth 2.1 promotes several previously-optional protections to required:

• PKCE on every authorization-code flow — not just public clients. Even confidential clients must use PKCE. This eliminates a class of code-interception attacks.
• Exact-match redirect URIs — no wildcard matching, no path-suffix matching. The IdP compares the redirect_uri to the registered URI byte-for-byte.
• Refresh-token rotation for public clients — each /token call with a refresh_token returns a *new* refresh_token; the old one is invalidated. Reuse of an old refresh token signals a possible compromise.
• Sender-constrained access tokens (recommended, not required) — DPoP or mTLS binding so a stolen bearer token cannot be replayed from a different client.

The Authorization Code + PKCE flow, end to end

This is now the universal default. Every other flow is a specialization. The flow:

# 1. Generate PKCE pair (client-side)
  code_verifier  = high-entropy random string (43-128 chars)
  code_challenge = base64url(sha256(code_verifier))

# 2. Redirect to /authorize
GET /authorize
  ?response_type=code
  &client_id=<client>
  &redirect_uri=<callback>
  &scope=openid profile
  &state=<csrf>
  &code_challenge=<challenge>
  &code_challenge_method=S256

# 3. User authenticates + consents → /callback?code=<auth_code>&state=<csrf>

# 4. Exchange code for tokens
POST /token
  grant_type=authorization_code
  &code=<auth_code>
  &redirect_uri=<callback>
  &client_id=<client>
  &code_verifier=<verifier>

# 5. Tokens returned
{
  "access_token": "...",
  "id_token": "...",
  "refresh_token": "...",
  "token_type": "Bearer",
  "expires_in": 3600
}

What "OAuth 2.1 compliant" actually means in practice

Most IdP product teams use "OAuth 2.1 compliant" as a marketing label. What it means concretely:

• The product accepts and validates PKCE on every authorization-code flow.
• The product does not offer the Implicit Flow or ROPC as default options.
• The product validates redirect_uri exactly against the registered URI.
• The product enforces refresh-token rotation (for public clients) and detects replay.

Migration checklist for an existing OAuth 2.0 codebase

Sequence that minimizes risk for an in-place upgrade:

• Audit existing flows. Find every place you call /authorize. List the grant type for each.
• Add PKCE to every authorization-code flow. Backwards-compatible: an IdP that doesn't understand PKCE will ignore the parameters.
• Eliminate the Implicit Flow. Replace every implicit-flow client with authorization-code + PKCE. SPA frameworks have supported this for years.
• Eliminate ROPC. If you still have it for legacy integrations, those need a real upgrade path (federated SSO or a service-account migration).
• Tighten redirect_uri registration. Move from wildcards to exact URIs.
• Enable refresh-token rotation. Many IdPs now offer this as a per-application toggle.