OAuth PKCE Generator: Create RFC 7636 Code Verifiers and Challenges
Public OAuth 2.0 clients — single-page applications, mobile apps, and desktop applications — cannot securely store a client secret. This makes them vulnerable to authorization code interception attacks. PKCE (Proof Key for Code Exchange) closes this vulnerability without requiring a secret.
Our generator uses the browser's Web Crypto API to create cryptographically random code verifiers and derive their SHA-256 challenges in a single click. All computation stays on your device.
The PKCE flow follows RFC 7636 Section 4:
The PKCE Authorization Flow
1. Client generates a random code_verifier (43-128 chars)
2. Client computes code_challenge = BASE64URL(SHA256(code_verifier))
3. Client sends code_challenge in the authorization URL
4. Authorization server stores the challenge with the auth code
5. Client receives the authorization code
6. Client sends code_verifier in the token exchange POST request
7. Server hashes the verifier and verifies it matches the stored challenge
8. Server issues access and refresh tokens
Why 43-128 Characters?
RFC 7636 requires the code_verifier to have a minimum entropy of 256 bits. Using the 66-character unreserved alphabet, at least 43 characters are needed to achieve this (log2(66^43) > 256). The 128-character maximum is set by practical URL length limitations. The recommended range of 64-96 characters provides ample security with comfortable URL lengths.
Practical Examples
React SPA with OAuth
- 1.Generate: verifier + challenge before redirect
- 2.Store: verifier in sessionStorage
- 3.Auth URL: append code_challenge and code_challenge_method=S256
- 4.Token call: POST with code_verifier from sessionStorage
Mobile app (iOS/Android)
- 1.Generate: verifier using SecRandomCopyBytes or SecureRandom
- 2.Challenge: SHA-256 then Base64URL encode
- 3.Auth: open system browser with challenge
- 4.Token: send verifier in background request
Frequently Asked Questions
What is PKCE in OAuth 2.0?
PKCE (Proof Key for Code Exchange, pronounced 'pixie') is a security extension to OAuth 2.0 defined in RFC 7636. It prevents authorization code interception attacks in public clients like SPAs, mobile apps, and native apps that cannot securely store a client secret.
How does PKCE work?
Before the authorization request, the client generates a random code_verifier. It hashes it with SHA-256 and Base64URL-encodes the result to get code_challenge. The challenge is sent with the authorization request. When exchanging the code for tokens, the original verifier is sent and the server verifies it matches the stored challenge.
What is the code_verifier?
The code_verifier is a cryptographically random string between 43 and 128 characters, using only URL-safe unreserved characters (A-Z, a-z, 0-9, hyphen, period, underscore, tilde). It must never be sent in the authorization URL - only in the token exchange POST body.
What is the code_challenge?
The code_challenge is BASE64URL(SHA256(ASCII(code_verifier))). It is sent as a query parameter in the authorization URL along with code_challenge_method=S256. The authorization server stores it and verifies the verifier during token exchange.
Should I use S256 or plain challenge method?
Always use S256. The plain method sends the verifier directly as the challenge, providing no security benefit. S256 is required for all new implementations and is the only method recommended by RFC 7636. Most authorization servers reject plain method.
Do SPAs need PKCE?
Yes. SPAs and mobile apps cannot securely store a client_secret, making them public clients. Without PKCE, an attacker who intercepts the authorization code can exchange it for tokens. PKCE mitigates this by requiring the original verifier that only the legitimate client knows.
Is the generated PKCE safe to use in production?
Yes. The tool uses the browser's built-in Web Crypto API (crypto.getRandomValues for the verifier, crypto.subtle.digest for SHA-256), which is cryptographically secure. The same APIs are used by production OAuth libraries.
Where do I send code_verifier vs code_challenge?
code_challenge goes in the authorization request URL (Step 1). code_verifier goes in the token exchange POST body (Step 2). Never send code_verifier in a URL - it would appear in server logs, browser history, and referrer headers.