1 min lesson
Why PKCE and why not implicit
Use the lesson to respond to this: "You're designing login for the Cursor desktop editor. Which flow and why that one over the alternatives?" Keep the answer plain.
Step 1 of 2
Why PKCE and why not implicitthe public-client story
Cursor's editor is a native app that talks to backend services and to SCM providers like GitHub. It has no safe place to store a client secret, so it uses Authorization Code + PKCE. The client generates a random code_verifier, sends its SHA-256 hash (code_challenge) on the authorize request, then proves possession of the verifier when redeeming the code. An attacker who intercepts the authorization code on the redirect cannot exchange it without the verifier.
code_verifier = random(64) // kept in memory on the client
code_challenge = base64url(sha256(code_verifier))
// 1. authorize: ?code_challenge=...&code_challenge_method=S256
// 2. user logs in -> redirect back with ?code=...
// 3. token: POST { code, code_verifier } // server recomputes the hashThe implicit flow returned tokens straight in the redirect URL fragment, where they leaked into browser history, referrer headers and logs. It is deprecated; PKCE replaced it for browser clients. If an interviewer asks why you avoided implicit, that is the whole answer and naming it signals you track the spec rather than copying a 2016 tutorial.
Learn more
Full explanation
Constraining blast radius
Constraining blast radiusredirect URIs and scopes
- Exact-match redirect URIs. Register the precise callback; reject wildcards and open redirects. A loose redirect turns PKCE's protection into theater because the code goes to the attacker's URL.
- Least-privilege scopes. A token that can only read one repo is a smaller breach than one that can write to every org the user belongs to. Scope is your blast-radius dial.
- `state` parameter. A random, verified
stateties the callback to the request you started and blocks CSRF on the redirect.