OAuth 2.0, OIDC and PKCE
Authorization Code + PKCE: step by step
Follow the proof chain from redirect to code exchange.
Understand the concept
The client generates a high-entropy code_verifier and derives an S256 code_challenge. The authorisation request includes that challenge plus the client, redirect, scope and required protections. After authentication and consent, the server redirects with a code. The client exchanges it at the token endpoint using the verifier and matching redirect context.
PKCE helps bind code redemption to the initiating client instance. It is not the same as authenticating a confidential client with a secret. Public browser and native clients cannot safely retain a permanent client secret. Redirect URIs need strict validation.
Codes should be short-lived and single-use. Handle cancellation, expiry and concurrent tabs. State and nonce have distinct responsibilities; PKCE is not a magical replacement for all protections. Use maintained identity libraries rather than a fragile handwritten exchange, and distinguish browser clients from server-side BFFs.
When debugging federated login flows.
Embedding a client secret in the browser or treating PKCE as access control.
One topic. Three levels of depth.
Create verifier → S256 challenge → authorisation requestThe verifier stays private; the challenge goes in the initial request.
This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.
Try it yourself first.
A callback code arrived but the verifier was lost. Can you generate a new random one?
Show the solution and explanation
No: restart the authorisation flow safely.No. A new value will not match the original challenge.