Authorization code flow with PKCE

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.

Together, these six steps mean the authorization code becomes worthless without its matching secret. Without step 2 (the hash binding), any intercepted code could be freely exchanged for tokens — which is the exact attack PKCE was designed to close.

The exact-match redirect URI rule

When you register a redirect URI with an identity provider, what stops an attacker from hijacking the code mid-flight by supplying their own destination? That’s exactly what open-redirect chaining exploits — and it’s why this rule exists.

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.