Authorization Code and PKCE

The client redirects the resource owner’s user agent to the authorization server’s /authorize endpoint as a plain GET with query parameters. Nothing in this request is confidential — it travels through the browser’s address bar, history, and any proxy in front of it — so it must never carry a secret.

On success, the authorization server redirects back to redirect_uri with the code and the client’s own state echoed unchanged, plus iss identifying which authorization server issued the response (RFC 9207) — the defence against mix-up attacks, covered in full on Security Best Practices.

The client must verify, before doing anything else with the response:

The user agent hands the code to the client at redirect_uri; the client then exchanges it for tokens with a direct, server-to-server POST that never touches the browser. This is where the client authenticates itself (see Client Credentials and Client Authentication for the full comparison of methods) and where the PKCE code_verifier is presented.

redirect_uri must be repeated here identically to the value sent in the authorization request — it is not used for another redirect, it is compared by the authorization server as proof the code redemption request comes from the same client that started the flow. client_id is required even for confidential clients that also authenticate via Authorization: Basic, since some authentication methods (e.g. private_key_jwt) do not carry it implicitly.

PKCE — Proof Key for Code Exchange, RFC 7636, pronounced "pixy" — closes a gap the base authorization code flow leaves open: without it, anything that can observe or intercept the authorization response (a malicious app registered for the same custom URI scheme on a mobile device, a network intermediary, a misconfigured redirect) can steal the authorization code and redeem it itself, because redeeming a code required nothing more than knowing it and, for a public client, no secret was ever in play to prevent that.

PKCE fixes this by binding the code to a secret only the client that started the flow knows:

Whoever intercepts the authorization code in transit does not have the code_verifier — it was never sent over that channel — so the stolen code is worthless to them. This is exactly the authorization-code interception attack PKCE was designed to stop.

These three values look similar — all three are client-generated, opaque-looking strings carried through the authorization request — but they protect three different things, and none of them substitutes for another.

All three are typically in play together on any OIDC authorization code request, and none is optional in a hardened deployment: skipping state reopens CSRF, skipping nonce on an OIDC request reopens ID-token replay, and skipping PKCE reopens code interception — three independent attacks with three independent, cheap defences.

RFC 9700 and OAuth 2.1 both mandate exact string matching of redirect_uri against the registered value — scheme, host, port, and path all compared byte-for-byte, with no wildcard subdomains and no pattern matching on the path. Query strings are the one place implementations vary: RFC 6749 allows a registered URI to be a prefix with the client appending additional query parameters, but this has been the source of real vulnerabilities (an attacker appending their own query parameters to redirect a code to a different endpoint on the same host), so current guidance — and OAuth 2.1 — treats the full registered URI, query string included, as the only acceptable match. Loosely matched redirect URIs are consistently the root cause behind open redirector and code-theft incidents; see Security Best Practices for the exact attack shapes this closes.

OpenID Connect defines hybrid response_type values (code id_token, code token, code id_token token) that return some tokens directly in the authorization response fragment alongside the authorization code — originally useful when a client wanted an ID token immediately, before completing the code exchange, to render a signed-in UI state without waiting on a round trip. The hybrid flow inherits the front-channel token exposure that motivates removing the pure implicit grant (see Legacy Implicit and Password Grants) for whichever tokens it returns directly, so current guidance treats it as a narrow, mostly legacy option: prefer the plain authorization code flow and read the ID token only after the code exchange completes, at which point the ID token was delivered over the back channel like everything else in this page. Full hybrid-flow mechanics are covered on OpenID Connect.