What is OAuth 2.1 and how does it differ from OAuth 2.0?

OAuth 2.1 (RFC 9700, draft 2023, finalized 2024) consolidates OAuth 2.0 best practices into a single specification. Key changes from 2.0: (1) PKCE is REQUIRED for ALL clients (not just public); (2) Implicit Flow REMOVED entirely; (3) Resource Owner Password Credentials Flow REMOVED entirely; (4) Refresh Token rotation REQUIRED for public clients; (5) Redirect URIs must use exact string matching (no wildcard subdomains); (6) Bearer tokens MUST NOT be passed in query strings (only Authorization header); (7) Detailed security guidance integrated. Backwards-compatible migration path defined for existing 2.0 deployments.

What is PKCE and why is it required in 2026?

PKCE (Proof Key for Code Exchange, RFC 7636, pronounced "pixie") prevents authorization code interception attacks. Workflow: client generates random code_verifier, derives code_challenge = SHA256(verifier), sends challenge with /authorize request, sends verifier with /token exchange. Server verifies SHA256(verifier) matches stored challenge. Originally for public clients only; OAuth 2.1 makes it mandatory for ALL clients including confidential. Implementation cost: 5-10 lines of code per client. No reason not to implement.

Why was Implicit Flow removed?

Implicit Flow (response_type=token) returned access tokens directly in the URL fragment after authorization. Multiple security issues: (1) tokens in browser history; (2) tokens in referer headers leaked to third-party scripts; (3) no replay protection; (4) browser address bar exposure; (5) lack of refresh token mechanism. Modern replacement: Authorization Code + PKCE works in all the same scenarios (SPAs, mobile apps) without these issues. Migration: most providers (Auth0, Okta, Microsoft, Google) now reject Implicit by default; required to opt-in legacy support.

What is the difference between OAuth and OIDC?

OAuth 2.0/2.1 is for AUTHORIZATION (delegated access to resources). OIDC (OpenID Connect) is for AUTHENTICATION (verifying user identity), built on top of OAuth. OIDC adds: (1) ID Token (JWT containing user identity claims) returned alongside access token; (2) UserInfo endpoint for fetching user profile; (3) standardized scopes (openid, profile, email, address, phone); (4) discovery via .well-known/openid-configuration. Use OAuth alone for "give my app access to your Gmail"; use OIDC for "log in with Google" (you also need to know who the user is).

What is refresh token rotation and why is it required?

Refresh token rotation: each time the client uses a refresh token to get a new access token, the authorization server issues a NEW refresh token and INVALIDATES the old one. If an attacker steals the refresh token and uses it before the legitimate client, the authorization server detects two clients using the same refresh token (refresh token reuse) and immediately revokes the entire token chain — forcing the user to reauthenticate. Without rotation, a stolen refresh token grants attacker indefinite access. OAuth 2.1 mandates rotation for public clients (SPAs, mobile apps where token storage is harder to secure).

Should I use ID Token for API authorization?

NO. ID Tokens are for authentication (proving WHO the user is). Access Tokens are for authorization (proving the user GRANTED PERMISSION to access something). Common antipattern: passing ID Token to API. Issues: (1) ID Tokens are typically longer-lived than necessary for API auth; (2) ID Tokens contain PII you don't want sent on every API request; (3) ID Tokens are designed for client to consume, not API to validate; (4) Audience claim mismatch — ID Token aud is the client_id, API aud is the resource server. Always pass Access Token to APIs.

What is Token Binding / DPoP?

DPoP (Demonstrating Proof of Possession, RFC 9449, 2023) cryptographically binds tokens to the client device. Client generates ephemeral keypair, signs each request with private key, server validates against public key. Even if attacker steals the bearer token, they can't use it without the matching private key. Recommended for high-security applications (banking, healthcare, government). Most current consumer apps still use bearer tokens without DPoP — easier to implement but less secure if token storage is compromised.

How do I migrate from OAuth 2.0 to 2.1?

Five-step migration: (1) Audit current flows — identify Implicit and ROPC usage; (2) Replace Implicit Flow clients with Authorization Code + PKCE (5-10 lines of code change); (3) Replace ROPC with Authorization Code + PKCE if interactive, or Client Credentials if M2M; (4) Add PKCE to all confidential clients; (5) Implement refresh token rotation for public clients. Most major identity providers (Auth0, Okta, Azure AD, Google, AWS Cognito) support OAuth 2.1 natively in 2026 — turning on rotation is typically a configuration toggle.

OAuth 2.1 vs 2.0 vs OIDC 2026 — Complete Migration Guide

Short answer: OAuth 2.1 (RFC 9700, 2024) consolidates OAuth 2.0 best practices into one spec with mandatory PKCE for ALL clients, Implicit Flow REMOVED, ROPC REMOVED, refresh token rotation REQUIRED for public clients, and strict redirect URI matching. OIDC is for authentication (login); OAuth alone is for authorization (delegated access). Always use Access Token for APIs, never ID Token. Migration is mostly configuration toggles in modern providers (Auth0, Okta, Azure AD, Google, Cognito).

OAuth flow status across 2.0 vs 2.1 vs OIDC

Flow	OAuth 2.0	OAuth 2.1	OIDC	Use case	Notes
Authorization Code + PKCE	Recommended	REQUIRED	Required	Web/SPA/mobile/desktop apps	Default modern flow
Authorization Code (no PKCE)	Allowed for confidential clients	PROHIBITED	Discouraged	Legacy server-to-server	Forbidden in OAuth 2.1; PKCE always required
Implicit Flow (response_type=token)	Allowed	REMOVED	Deprecated	Old SPAs	Vulnerable to token leakage; replaced by Auth Code + PKCE
Resource Owner Password Credentials (ROPC)	Allowed	REMOVED	Discouraged	Legacy username/password apps	Anti-pattern; client sees password
Client Credentials	Allowed	Allowed	N/A (no user)	M2M / service-to-service	Only flow without user; no user identity returned
Refresh Token (no rotation)	Allowed	REQUIRES ROTATION for public clients	Recommended rotation	Long-lived sessions	Replay attack mitigation
Refresh Token (with rotation)	Recommended	REQUIRED for public clients	Standard practice	SPA/mobile sessions	Each use returns new RT; old RT invalidated
Device Authorization Grant	RFC 8628 (extension)	Standardized	Used for TV/CLI	Smart TV / CLI / IoT	User authorizes on second device with code
CIBA (Client-Initiated Backchannel Auth)	Extension	Extension	OIDC CIBA	Banking, regulated finance	Push notification-based auth

PKCE — step by step

Step	Detail
1. Client generates code_verifier	Random 43-128 char string [A-Z, a-z, 0-9, "-._~"]
2. Client generates code_challenge	SHA256(code_verifier), base64url-encoded (S256 method)
3. /authorize request	Includes code_challenge and code_challenge_method=S256
4. Authorization Server stores code_challenge	Bound to issued authorization code
5. /token exchange	Client sends code_verifier; AS verifies SHA256(code_verifier) === stored code_challenge
6. Tokens issued	Access token + refresh token returned

Code example — Authorization Code + PKCE (Node.js)

// Step 1-2: Generate code_verifier + code_challenge
import crypto from 'crypto';

function generateVerifier() {
  return crypto.randomBytes(32).toString('base64url');
}

function generateChallenge(verifier) {
  return crypto.createHash('sha256').update(verifier).digest('base64url');
}

const code_verifier = generateVerifier();
const code_challenge = generateChallenge(code_verifier);

// Store code_verifier in session for /token call later
sessionStorage.setItem('pkce_verifier', code_verifier);

// Step 3: /authorize request
const authUrl = new URL('https://issuer.example.com/authorize');
authUrl.searchParams.set('response_type', 'code');
authUrl.searchParams.set('client_id', CLIENT_ID);
authUrl.searchParams.set('redirect_uri', REDIRECT_URI);
authUrl.searchParams.set('scope', 'openid profile email');
authUrl.searchParams.set('state', generateState());
authUrl.searchParams.set('code_challenge', code_challenge);
authUrl.searchParams.set('code_challenge_method', 'S256');
window.location.href = authUrl.toString();

// Step 4-5: After redirect with code, /token exchange
const verifier = sessionStorage.getItem('pkce_verifier');
const tokenResponse = await fetch('https://issuer.example.com/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    grant_type: 'authorization_code',
    code: callbackCode,
    redirect_uri: REDIRECT_URI,
    client_id: CLIENT_ID,
    code_verifier: verifier,  // PKCE verifier
  }),
});

const { access_token, refresh_token, id_token } = await tokenResponse.json();

Token type cheat sheet

Token	Purpose	Pass to	Lifetime
Access Token	Authorization (API access)	Resource Server (API)	5-60 min typical
Refresh Token	Get new Access Token without user re-login	Authorization Server only	7-90 days typical
ID Token (OIDC)	Authentication (who is the user)	Client only — NEVER to API	5-60 min typical

5-step migration from OAuth 2.0 → 2.1

Audit current flows. Search codebase for `response_type=token` (Implicit) and `grant_type=password` (ROPC).
Replace Implicit with Authorization Code + PKCE. 5-10 lines per client. Modern auth libraries handle PKCE automatically (Auth0 SPA SDK, MSAL, NextAuth).
Replace ROPC. If interactive: use Authorization Code + PKCE. If M2M: use Client Credentials.
Add PKCE to all confidential clients. No-cost security upgrade.
Enable refresh token rotation. Most providers have a config toggle. Verify your client handles refresh-on-each-use correctly.

Related Bytepane resources

Sources: RFC 9700 (OAuth 2.1, finalized 2024), RFC 7636 (PKCE), RFC 8252 (OAuth 2.0 for Native Apps), RFC 9449 (DPoP, 2023), OpenID Connect Core 1.0 (errata set 1, 2023), IETF OAuth Working Group security topic drafts (current). Provider documentation: Auth0, Okta, Microsoft Identity Platform, Google Identity Services, AWS Cognito. Always test migration in non-production environment first; some providers have provider-specific PKCE quirks (e.g., Microsoft requires explicit S256 method declaration).