PKCE: secure OAuth login for apps and browsers

In short: PKCE (pronounced “pixie”) protects the OAuth code flow from someone redeeming an intercepted code. When redeeming, the application proves it is the same one that started the flow.

The problem

In the OAuth flow the provider returns to the application with a short code. Apps and browser applications have no secret password to show when redeeming. If an attacker intercepts the code (for example through a manipulated redirect), they could redeem it themselves.

How PKCE works

1. The application generates a long random value, the code verifier.
2. It derives the code challenge from it with SHA-256 and sends only that at the start.
3. The provider remembers the challenge and returns the code.
4. When redeeming, the application sends the verifier. The provider recomputes whether it matches the challenge.

An attacker who knows only the code doesn’t know the verifier. The verifier can’t be computed back from the challenge because a hash only goes one way (Hashing).

Where it is required or standard

For public clients (mobile apps, single-page applications) PKCE is mandatory. For server applications it is now also recommended, in addition to state and, with OpenID Connect, nonce.

Typical mistakes

• Using challenge method plain instead of S256.
• Generating the verifier without enough randomness (too short, predictable).
• Storing the verifier where other pages can read it.