Authorization code flow with PKCE

An attacker monitors a mobile app’s outgoing requests and captures the one-time authorization code in the redirect URL. Without PKCE, they exchange the code for tokens and own the account. PKCE is the lock that makes a stolen code worthless.

How PKCE works — step by step

PKCE (Proof Key for Code Exchange, RFC 7636) adds a cryptographic challenge to the authorization code flow. OAuth 2.1 mandates it for every client, including confidential server-side apps.

Before the redirect:

1. Client generates a code_verifier — a random 43–128 character URL-safe string (cryptographically random).
2. Client computes code_challenge = base64url(SHA-256(code_verifier)).
3. Client sends the code_challenge (but NOT the code_verifier) to the authorization server in the /authorize request.

After user consent: 4. Authorization server returns a one-time code in the redirect. It stores the code_challenge alongside the code.

Token exchange: 5. Client POSTs to /token with the code AND the original code_verifier. 6. Authorization server hashes the code_verifier, compares to the stored code_challenge. Match → tokens issued. No match → request rejected.

An attacker who intercepts the code in step 4 cannot redeem it — they need code_verifier, which was never sent over the wire.

The exact-match redirect URI rule

OAuth 2.1 requires the redirect_uri in the token request to exactly match a pre-registered URI — no wildcards, no path prefixes, no partial matches.

Without this rule: an attacker can trigger a flow with redirect_uri=https://yourapp.com/comments?next=https://attacker.com. If your app has any open-redirect on /comments, the authorization code lands on the attacker’s server. The exact-match rule shuts this down: the URI must be character-for-character identical to a registered value.

For native apps where you cannot reliably register a URL (deep links, custom URI schemes), OAuth 2.1 + RFC 8252 require either http://127.0.0.1:RANDOM_PORT (loopback) or a private-use URI scheme registered with the OS.

State and nonce: two separate anti-attack tokens

State is OAuth’s anti-CSRF: the client generates a random value at /authorize time, the server echoes it back in the redirect, the client verifies it matches. Without state, an attacker can send a victim a crafted /authorize URL pointing to the attacker’s redirect — on click, the victim’s browser silently completes the flow under the attacker’s account.

Nonce is OIDC’s anti-replay: the client sends a random value in /authorize; the IdP embeds it inside the id_token. The client verifies the nonce in the token matches what it sent. Without nonce, an attacker who captures an id_token from another channel can replay it to a different session.

Both are random per-request. Both are validated server-side. Neither is optional in modern flows.