PKCE (Proof Key for Code Exchange)
|
|
🔐 What is PKCE?
PKCE (Proof Key for Code Exchange, pronounced “pixie”) is an extension to the OAuth 2.0 Authorization Code flow.
It prevents intercepted authorization codes from being exchanged by attackers — especially important for public clients (mobile apps, SPAs, desktop apps) that cannot securely store a client secret.
⚙️ How PKCE Works (High-level)
- Code Verifier: Client generates a long random string (43–128 chars).
- Code Challenge: Client derives a challenge (usually SHA-256 of verifier, base64url-encoded) and sends it with the authorization request.
- Auth Code Issued: Authorization server returns an authorization code to the client after user consent.
- Token Exchange: Client sends the authorization code plus the original code verifier to the token endpoint.
- Validation: Server hashes the supplied verifier and compares it to the earlier challenge; if they match, tokens are issued.
📘 Example (simplified)
Client side:
code_verifier = "random-long-string..."
code_challenge = BASE64URL(SHA256(code_verifier))
Redirect to:
https://auth.example.com/authorize?response_type=code&client_id=...&code_challenge=code_challenge&code_challenge_method=S256
Token request:
POST /token
grant_type=authorization_code
code=AUTH_CODE
client_id=...
code_verifier=random-long-string...
✅ Benefits
- Prevents use of stolen authorization codes by attackers.
- No client secret required for public clients.
- Now recommended as best practice for most OAuth flows (SPAs, mobile, native apps).
📌 When to Use
- Single-page applications (SPAs)
- Mobile and desktop/native applications
- Any OAuth 2.0 flow where the client cannot safely store a secret
🔒 Notes & Tips
- Always use
S256 (SHA-256) as the code_challenge_method when supported.
- Generate a high-entropy random verifier and keep it only in the client until token exchange.
- PKCE complements other security measures (HTTPS, secure redirect URIs, token lifetimes).
