Why it matters
PKCE (Proof Key for Code Exchange) protects the OAuth authorisation code flow: the app makes a random secret, sends only its hash when the user signs in, and proves it has the secret when it swaps the code for tokens. A stolen code is useless without it. OAuth 2.1 and current best practice require PKCE for every client, not just mobile apps.
Most failures are small: a verifier that is too short, a challenge in standard rather than URL-safe base64, a redirect URI that differs between the two requests, or a state that isn't checked. This simulator builds each request, checks the response your browser actually received, and shows where it went wrong.
How to use it
- Enter the endpoints, client_id, redirect URI and scopes.
- Use the generated verifier and state, or paste your own.
- Open the authorisation URL and sign in.
- Paste the URL you were redirected to, then run the token request it gives you.
FAQ
What is PKCE?
An extension to the OAuth code flow (RFC 7636). The app sends a hash of a random secret when the user signs in and the secret itself when redeeming the code, so an intercepted code can't be used.
Should I use S256 or plain?
S256. With plain the challenge is the secret itself, so anyone who sees the authorisation request can redeem the code.
Do I still need state with PKCE?
Yes, it is still recommended. PKCE stops stolen codes being redeemed; state ties the response to the user's own browser session and carries app context.
Why is my token request rejected with invalid_grant?
The code was already used or expired, the redirect_uri differs from the authorisation request, or the code_verifier doesn't hash to the challenge.
