OAuth 2.0 with PKCE Explained

Why PKCE exists

In the plain Authorization Code flow, an attacker who intercepts the one-time code (via a redirect leak, a malicious app, etc.) can exchange it for tokens. PKCE (Proof Key for Code Exchange) fixes that: the client proves it's the same party that started the flow. It's now the standard for public clients (SPAs, mobile) - and replaces the deprecated implicit grant.

The flow

1. Client generates a random code_verifier and its code_challenge = base64url(SHA256(verifier)).
2. /authorize: client sends the challenge (+ code_challenge_method=S256). The server stores it with the issued code.
3. /token: client exchanges the code plus the raw code_verifier.
4. Server verifies: SHA256(verifier) must equal the stored challenge. Match -> issue tokens. Mismatch -> reject.

A stolen code is useless without the matching verifier, which never left the client.

The check that makes it secure

This is the step that's easy to skip (and fatal to skip) - the token endpoint must verify the verifier before issuing a token:

import hashlib, base64

def verify_pkce(code_verifier: str, stored_challenge: str) -> bool:
    digest = hashlib.sha256(code_verifier.encode()).digest()
    computed = base64.urlsafe_b64encode(digest).rstrip(b"=").decode()  # base64url, no padding
    return computed == stored_challenge

# in /token:
if not verify_pkce(request.form["code_verifier"], entry["code_challenge"]):
    return jsonify({"error": "invalid_grant"}), 400
# only now issue the access token

The details that bite people

• Use S256, not plain. The plain method sends the verifier as the challenge - no protection. Always code_challenge_method=S256.
• base64url, no padding. The challenge is base64url (URL-safe alphabet) with the = padding stripped - get this wrong and every comparison fails.
• One-time codes, short TTL. The code must be single-use and expire fast.
• Still validate redirect_uri - PKCE complements, not replaces, exact redirect-URI matching.