What is PKCE and why use it?

PKCE (Proof Key for Code Exchange) hardens the OAuth 2.0 authorization-code flow against interception. Your app generates a random secret called the code_verifier, sends a hash of it (the code_challenge) when starting the login, and then sends the original verifier when exchanging the code for tokens. Because only your app knows the verifier, an attacker who intercepts the authorization code cannot exchange it. It is now recommended for all OAuth clients, and required for public clients like SPAs and mobile apps.

Always S256. The code_challenge_method can be plain (the challenge equals the verifier) or S256 (the challenge is the base64url SHA-256 of the verifier). plain offers no real protection if the request is intercepted, so use S256 everywhere it is supported, which is essentially everywhere. This tool generates S256.

Where does the verifier need to be stored?

Generate the verifier when you start the auth flow and keep it somewhere only your app session can read - typically session storage in a browser app, or a short-lived server session - until the token exchange. It must survive the redirect to the authorization server and back, and then it is used once and discarded. Never expose it in the URL or to other origins.

Free tool · Runs in your browser · Nothing uploaded

PKCE for OAuth 2.0.

PKCE hardens the OAuth authorization-code flow so an intercepted code is useless to an attacker. Generate a cryptographically random code_verifier and its matching S256 code_challenge — correct length, base64url, SHA-256 — ready to drop into your flow.

code_verifier

—

code_challenge (S256)

—

code_challenge_method

S256

The proof only your app holds

The authorization-code flow has a gap: the code comes back through a redirect, and on a public client — a single-page app, a mobile app — there is no client secret to prove the code is being redeemed by the app that requested it. Anyone who intercepts the code could try to exchange it. PKCE closes that gap with a one-time secret your app generates and never sends in the clear: it commits to a hash up front, then reveals the original at the end, so only the app that started the flow can finish it.

It’s a clean example of the same idea everywhere in security: prove you are who you say with something only you hold, and keep that something controlled. Managing the secrets and flows that authenticate access to the backend you own is part of what a control plane keeps honest.

Related free tools

UFW firewall generatorLock down your server SSH hardening generatorLock down sshd_config fail2ban config generatorAuto-ban brute-forcers nginx rate limit generatorCap abuse + brute force

All free tools →

Auth you can verify, on infrastructure you own.

Infraveil runs your backend on servers you own with access governed and secrets managed — so the flows that let people and services in are ones you control and can audit, end to end.

See how it works

Get the auth-security playbook

OAuth, PKCE, tokens, and secrets done safely for a backend you run yourself. No spam.