What is PKCE?

PKCE (Proof Key for Code Exchange), explained#

In the authorization code flow, the code travels back to the app through a redirect. On a phone, a desktop app or a browser-based app, that redirect can be intercepted, by another app registered for the same URL scheme or by a leaked log. Before PKCE, a public client had no secret to prove the code was really its own, so whoever held the code could redeem it.

PKCE adds a one-time secret per sign-in. The app generates a high-entropy random string, the code_verifier, and keeps it. It computes code_challenge = BASE64URL(SHA256(code_verifier)) and sends the challenge with code_challenge_method=S256 in the authorization request. The authorization server stores the challenge alongside the code it issues.

When the app exchanges the code at the token endpoint, it sends the code_verifier. The server hashes it and compares the result with the stored challenge. An attacker who intercepted the code never saw the verifier, only its hash, and cannot reverse it, so the exchange fails.

RFC 7636 also allows a plain method where the challenge equals the verifier. That protects less, because the secret then travels in the authorization request itself, and OAuth 2.1 and the MCP specification tell clients to use S256 when they can. MCP clients must also check the authorization server's metadata for code_challenge_methods_supported and refuse to continue if PKCE is not supported.

For example, a command-line tool starts sign-in by opening the browser to the authorize URL with a challenge. It listens on a loopback address for the redirect, receives the code, and posts it to the token endpoint with the verifier it kept in memory. A malicious local app that grabbed the same redirect gets a code it cannot use.