The Authorization Code Flow (with PKCE)

The user's browser has to be involved: it is where the user authenticates and consents. But the browser is also the least trustworthy place to put anything valuable — URLs land in history, in referrer headers, in server logs, and in any application registered to handle the URI scheme.

The authorization code flow resolves this by sending something through the browser that is nearly worthless on its own: a one-time authorization code, valid for seconds, usable once, and redeemable only by the client that requested it. The tokens themselves travel on the back channel — a direct server-to-server request from the client to the authorization server, over TLS, authenticated with the client's own credentials.

So if the code leaks — through a log, a referrer, or an intercepted redirect — the attacker still needs the client's secret to exchange it. That is the whole design, and it is why the older implicit flow, which returned tokens directly in the redirect fragment, is deprecated: it put the valuable thing in the observable channel.

The back-channel design assumes the client can keep a secret. A single-page application or a mobile app cannot — its code is on the user's device and anything embedded in it is extractable. For those public clients, the code alone would be sufficient for anyone who intercepts it, which on mobile was a real attack: a malicious app registering the same custom URI scheme receives the redirect and redeems the code.

PKCE (Proof Key for Code Exchange) fixes this without a stored secret. The client generates a random code_verifier per authorization request, sends only its hash (code_challenge = SHA256(verifier), with code_challenge_method=S256) in the front-channel request, and presents the original verifier when exchanging the code. The authorization server hashes it and compares. An attacker who intercepts the code does not have the verifier, which never left the client, so the code is unredeemable.

Current guidance is to use PKCE for all clients, confidential ones included. It costs almost nothing and defends against code interception regardless of whether a client secret is also in play. Always use S256; the plain method sends the verifier itself in the front channel and provides nothing.

Redirect URI validation must be an exact match against a pre-registered value. Prefix or wildcard matching is repeatedly exploitable: a registration of https://app.example/callback matched by prefix also matches https://app.example/callback.evil.com under a careless implementation, and a registered path on a domain with an open redirect lets an attacker bounce the code onward to a host they control. Open redirects are usually filed as low severity; combined with an OAuth callback they are an account-takeover primitive.

`state` is a CSRF token for the callback. Without it, an attacker can initiate an authorization flow with their own account, capture the resulting code, and then cause a victim's browser to visit the callback with that code — linking the attacker's third-party account to the victim's session, or vice versa. Generate state randomly per request, store it server-side, and compare on return. Do not put a secret inside it; it is an identifier, not a container.

`nonce` is separate and does a different job: it binds an OIDC id_token to this specific authorization request so that a previously-obtained token cannot be replayed into a new login. Both are needed for a login flow; state alone for a pure API-access flow.

Two more, briefly. Codes must be single-use and short-lived, and a second redemption attempt should invalidate the grant, since it indicates interception. And the redirect_uri sent at exchange must match the one sent at authorization — a check that closes a family of mix-up attacks in multi-provider setups.