OAuth PKCE Code Verifier & Challenge Generator

About the OAuth PKCE Code Verifier & Challenge Generator

PKCE (Proof Key for Code Exchange, RFC 7636) protects the OAuth authorization code flow: the app makes a secret code_verifier, sends its SHA-256 — the code_challenge — with the authorization request, and proves it holds the verifier when it exchanges the code for tokens. A stolen authorization code is then useless. RFC 9700, the OAuth security best current practice, makes PKCE mandatory for public clients and recommends it for every other client.

This page makes a verifier exactly as RFC 7636 recommends (32 random octets in base64url from your browser’s Web Crypto), its S256 challenge, and a random state and nonce. Type your client settings and it builds the authorization request URL and the token request as a curl command. It also checks whether a verifier matches a challenge — and names the usual mistake when it does not — and reads an authorization request you paste against RFC 7636 and RFC 9700. Nothing is sent anywhere: the requests are built and read in this tab.

Without a pass you see a free preview: the first characters of each value and the first lines of each request, every pair check’s verdict and the counts of a request check with its first checks. The whole values and requests, and copying or downloading them, unlock with a Pro pass.

Common uses

• Testing a single-page app’s or a mobile app’s sign-in against an OAuth or OpenID Connect provider by hand, before the code is written.
• Finding out why a token request fails with invalid_grant: a challenge encoded with the wrong Base64, sent as plain, or computed from different bytes.
• Reviewing the authorization requests an app sends: PKCE present, S256, an unguessable state, no tokens or secrets in the URL.
• Explaining PKCE in a workshop with real values that match the RFC’s formula.

How PKCE works

1. The app makes a fresh code_verifier for each authorization request: 43 to 128 characters from A–Z, a–z, 0–9 and - . _ ~ (RFC 7636 §4.1).
2. It sends code_challenge = BASE64URL(SHA256(ASCII(code_verifier))) and code_challenge_method=S256 with the authorization request (§4.2, §4.3).
3. With the authorization code it sends the code_verifier in the token request (§4.5).
4. The server hashes the verifier and compares it with the challenge it stored; a mismatch fails with invalid_grant (§4.6).

Whoever intercepts the code — another app on the phone that registered the same redirect, a log, a browser extension — cannot redeem it, because the verifier never left the app.

state, nonce and PKCE

• state is a one-time value the app keeps for the browser session and checks on the redirect. RFC 9700 says a client may rely on PKCE’s protection against cross-site request forgery once it knows the server supports PKCE; if the server does not, state or nonce MUST be used (RFC 9700 §2.1, §4.7.1). Many apps also use state to return the visitor to where they were.
• nonce belongs to OpenID Connect: it travels into the ID token, and the app checks the ID token’s nonce claim against the value it sent (OpenID Connect Core 1.0, §3.1.3.7). OpenID Connect requires “sufficient entropy” for it; this page uses 128 random bits for both.

Mistakes the pair check names

• Plain sent as S256, or no code_challenge_method at all, which means plain (RFC 7636 §4.3).
• Standard Base64 (+, /, = padding) instead of base64url — the most common one.
• The hash written in hex instead of base64url.
• Hashing the decoded bytes of a base64url verifier instead of its ASCII text.
• Spaces or line breaks copied with a value.

What RFC 9700 asks of a client

• Public clients (single-page and mobile apps) MUST use PKCE; it is RECOMMENDED for confidential clients.
• Use a challenge method that does not expose the verifier — today that is S256.
• Clients SHOULD NOT use the implicit grant (response_type=token); use code with PKCE instead (§2.1.2).
• Register exact redirect URIs: servers MUST compare them as exact strings, and only the port of a native app’s loopback redirect may vary.
• Authorization responses MUST NOT travel over unencrypted connections, so servers must not allow http redirect URIs, except a native app’s loopback redirect (§2.6).

Limitations

• The page builds and reads requests; it never sends them. To try a flow, open the authorization URL yourself and exchange the code with the curl command.
• A request check reads the request’s form. Whether your server enforces PKCE, accepts the redirect URI or knows the client can only be seen by running the flow.
• For production, your app must make a new verifier, state and nonce for every sign-in at run time. Values made here are for testing, debugging and learning.
• Confidential clients also authenticate in the token request (client_secret_basic, private_key_jwt and others); the curl command leaves that part to you.

Privacy

On this device: nothing is sent

Everything is made and read in this tab with your browser’s Web Crypto: no value, URL or setting is uploaded or stored. Only the choices of length, method and nonce are remembered in this browser.