PKCE Code Challenge Generator
Generate a random code verifier and its S256 challenge for an OAuth sign-in, or paste your own verifier to work out its challenge.
Worked examples
The example in RFC 7636
Verifier: dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
Use this pair to check that your own code is correct.
About PKCE Code Challenge Generator
PKCE, short for Proof Key for Code Exchange, is a small addition to the OAuth sign-in flow that makes it much harder to steal a login. Before sending the visitor to sign in, your app invents a secret called the code verifier and sends only its fingerprint, the code challenge. When it later swaps the returned code for tokens, it has to present the original verifier. An attacker who intercepted the code on its way back cannot do that, so the stolen code is useless. It is defined in RFC 7636 and is now expected for apps of every kind.
This page makes the pair for you. It builds a random verifier from the characters the standard allows, between 43 and 128 of them, and works out the S256 challenge, which is the SHA-256 hash of the verifier written in URL-friendly Base64. You can also paste a verifier of your own to see its challenge, which is handy for testing your code against a known answer. Random state and nonce values are made alongside, because a sign-in request should carry fresh ones too.
How to use PKCE Code Challenge Generator
- Choose a verifier length. 64 characters is plenty.
- Press Make new values to create a verifier, a state and a nonce, or paste your own verifier.
- Copy the code challenge and send it with code_challenge_method set to S256.
- Keep the verifier until the code exchange, where you send it to the token address.
Common uses
- Testing the sign-in flow of a single page app or mobile app by hand
- Checking that your PKCE code produces the right challenge
- Making values for a manual test in an API client
- Learning how the verifier and challenge relate
Frequently asked questions
What is the difference between the verifier and the challenge?
The verifier is the secret and is kept by your app. The challenge is its SHA-256 fingerprint, fine to send in the sign-in request. Nobody can turn the challenge back into the verifier, but your app can prove it knows the verifier later.
Why use S256 and not plain?
Plain sends the verifier itself as the challenge, so it protects nothing if the request is seen. S256 hides the verifier. The standard says to use S256 whenever the client can.
How long should a verifier be?
Between 43 and 128 characters, using letters, numbers and the symbols - . _ ~. A 64 character verifier made from random bytes has plenty of strength.
Can I reuse a verifier?
No. Make a new one for every sign-in attempt and discard it after the exchange. Reuse removes the protection.
What are state and nonce for?
State ties the returned request to the one you started, which blocks forged returns. The nonce ties an identity token to the request, which blocks replay. Both should be random and checked when the user comes back.