OAuth 2.1 Changes — What Developers Need to Update

OAuth 2.1 is the consolidation of the original OAuth 2.0 spec with the security updates from six years of BCP (Best Current Practice) documents. It does not introduce new features — it formalises what was already best practice and removes what is no longer safe.

What is removed in OAuth 2.1

1. Implicit Flow (response_type=token) — REMOVED

The Implicit Flow returns tokens directly in the URL fragment. This means access tokens appear in browser history, server logs, and can be leaked via the Referer header. All OAuth 2.1 clients must use Authorization Code + PKCE instead.

# OAuth 2.0 — Implicit Flow (do not use)
GET /authorize?response_type=token&client_id=...
# Returns: https://app.com/callback#access_token=eyJ...  ❌ token in URL

# OAuth 2.1 — Authorization Code + PKCE (correct)
GET /authorize?response_type=code&code_challenge=...&code_challenge_method=S256
# Returns: https://app.com/callback?code=abc123  ✅ code, not token

2. Resource Owner Password Credentials (ROPC) — REMOVED

The password grant requires the client to collect and transmit the user's username and password — defeating the security purpose of OAuth. Remove any grant_type=password flows in your applications.

# Do not use
POST /token
grant_type=password&username=user@example.com&password=secret  ❌

# Use authorization code flow instead — user logs in at the auth server

What is now required in OAuth 2.1

PKCE required for all clients

PKCE (Proof Key for Code Exchange) was previously only required for public clients (SPAs, mobile apps). OAuth 2.1 requires PKCE for all authorization code flows — including confidential clients (server-side apps with a client secret).

// All OAuth 2.1 authorization requests must include:
const params = new URLSearchParams({
  response_type: 'code',
  client_id: CLIENT_ID,
  redirect_uri: REDIRECT_URI,
  code_challenge: challenge,          // required
  code_challenge_method: 'S256',      // required — plain is not allowed
  scope: 'openid profile',
});

Redirect URI exact matching

OAuth 2.1 mandates exact string matching for redirect URIs. Partial path matching and wildcard patterns are prohibited. All environments (dev, staging, production) must be registered as separate URIs.

Bearer token transmission

Access tokens must only be sent in the Authorization header. Sending tokens in URL query parameters (?access_token=...) is prohibited in OAuth 2.1.

# Correct — Authorization header
GET /api/resource HTTP/1.1
Authorization: Bearer eyJhbGc...  ✅

# Prohibited — URL parameter
GET /api/resource?access_token=eyJhbGc...  ❌

What OAuth 2.1 does not change

• Client Credentials flow — unchanged, no PKCE required for machine-to-machine
• Refresh Token flow — unchanged
• Device Authorization flow — unchanged
• Token formats — no requirement for JWT, opaque tokens still valid
• Scope semantics — no changes

Provider support status

Migration checklist

• Find all response_type=token flows and replace with Authorization Code + PKCE
• Find all grant_type=password flows and replace with a redirect-based flow
• Add PKCE to server-side apps that use Authorization Code without it
• Ensure all redirect URIs are registered as exact strings in provider dashboards
• Audit any code that appends tokens to URLs