Walk through the OAuth2 authorization code flow with PKCE, step by step

#Why PKCE exists

The OAuth2 authorization code flow was originally designed assuming a confidential client — a server-side application that can hold a client_secret safely, away from end users. Single-page apps, mobile apps, and native desktop apps cannot make that assumption: anything shipped to the client can be extracted from it, so a hardcoded secret provides no real protection. Worse, on native platforms the redirect back to the app after login typically goes through a custom URI scheme (myapp://callback) or a universal link, and more than one app on the same device can sometimes register the same scheme — opening a window for a malicious app to intercept the authorization code meant for the legitimate one.

PKCE — Proof Key for Code Exchange, RFC 7636, pronounced "pixy" — closes that gap without requiring any shared secret at all. It binds the request that starts the flow to the request that finishes it, so that even if an attacker intercepts the authorization code in transit, they cannot exchange it for a token.

#The moving parts

• code_verifier — a high-entropy random string the client generates itself, kept only in memory or session storage, and never transmitted until the very last step.
• code_challenge — BASE64URL(SHA256(code_verifier)), sent up front in the authorization request. Because SHA-256 is one-way, possessing the challenge does not let anyone recover the verifier.
• code_challenge_method — S256 in every modern implementation; the plain method (sending the verifier itself as the challenge) exists for legacy compatibility only and provides no real protection.

#Step by step

1. The client generates a code_verifier and derives code_challenge = BASE64URL(SHA256(code_verifier)).
2. The client redirects the user's browser to the authorization server's /authorize endpoint, including client_id, redirect_uri, response_type=code, scope, a random state value, code_challenge, and code_challenge_method=S256.
3. The authorization server authenticates the resource owner — a login prompt, possibly MFA — and asks for consent to the requested scopes.
4. On approval, the authorization server redirects back to redirect_uri with a short-lived code and the original state echoed back.
5. The client checks that the returned state matches what it sent in step 2 (this is the CSRF defense — it is a separate concern from PKCE), then makes a direct, back-channel POST to the /token endpoint with grant_type=authorization_code, code, redirect_uri, client_id, and — critically — the raw code_verifier.
6. The authorization server recomputes SHA256(code_verifier) and compares it against the code_challenge it stored when it issued the code. A mismatch means the party exchanging the code is not the party that started the flow, and the request is rejected.
7. On a match, the authorization server issues an access_token (and typically a refresh_token, plus an id_token if this is OpenID Connect).
8. The client calls the resource server with Authorization: Bearer <access_token>.
9. The resource server validates the token — checking the signature and claims if it is a JWT?, or calling an introspection endpoint if it is opaque — and serves the protected resource.

#Why interception still fails

🧠 Check your understanding
0/3 · 0/3 answered
1. What problem does PKCE solve that the plain OAuth2 authorization code flow does not, for public clients like SPAs and mobile apps?
It encrypts the access token while it is in transitIt replaces the need for HTTPS between the client and the authorization serverIt prevents a party who intercepts the authorization code from exchanging it for a token, without requiring the client to hold a secretIt lets the client skip the user login step entirely
2. In the PKCE flow, when is the code_verifier itself sent to the authorization server?
Only in the final /token exchange request, never beforeIt is never sent — only its hash is ever transmittedIn every request, as an HTTP headerIn the initial /authorize redirect, alongside the code_challenge
3. What does the state parameter protect against that PKCE does not?
Cross-site request forgery (CSRF) against the redirect callbackAuthorization code interception by a malicious app on the same deviceMan-in-the-middle attacks against the TLS connection itselfAccess token expiry