Mini OAuth 2.0 + PKCE login

Stand up the minimal authorization server: an /authorize endpoint that accepts client_id, redirect_uri, response_type=code, scope, and a PKCE code_challenge (S256 only — reject plain), and a client that initiates the flow. The authorization code is a one-time, short-lived bearer of intent: keep its TTL tight (30–60 s, single use) because it travels through the browser and the redirect query string, the most exposed leg of the whole flow. PKCE binds the eventual token exchange to the browser that started it: the client generates a 43–128 char high-entropy code_verifier (≥256 bits from a CSPRNG), sends only its SHA-256 challenge up front, and reveals the verifier at the token step — so an intercepted code is useless without the verifier. The tradeoff: PKCE adds zero server-stored secret (unlike a confidential client secret) which is exactly why it's mandatory for public/native clients that cannot hold a secret.

Build the /token endpoint that exchanges code + code_verifier for an access token and a refresh token. Verify the verifier (SHA-256(code_verifier) == stored challenge) and consume the code atomically so a replayed code fails. Sign access tokens as JWTs with an asymmetric key (RS256/ES256, not HS256 — resource servers must verify with a public key, never share the signing secret), keep access-token TTL short (5–15 min) so a leaked token expires fast, and make refresh tokens long-lived opaque handles. Publish a JWKS endpoint with a kid in each token header so you can rotate signing keys without downtime: roll in a new key, serve both in JWKS during an overlap window (≥ your max token TTL), then retire the old kid. The tradeoff is self-contained JWTs (no introspection round-trip, but you can't revoke a live one) versus opaque tokens (revocable, but every check is a network hop).

Connect the relying-party client to your server end to end and validate the ID token before trusting a single claim. The callback handler must check the returned state against the value it stored before redirecting (this is the CSRF defense for the flow — without it, an attacker can stitch their own code into your victim's session), then exchange the code. Validate the ID token's signature against JWKS, plus iss, aud, exp, and nonce — a missing aud check means your app would accept a token minted for a different client. Pin the redirect target: only ever redirect the browser back to a validated, registered URI, because a sloppy 'return to' parameter is the classic open-redirect that turns your login into an attacker's launch pad.

Make authorization mean something. Add a consent step where the resource owner approves the specific scopes a client requested, and enforce least privilege: a token granted read:profile must not pass a write:billing check. Issue tokens carrying only the consented scopes, and add two RFC 7662/7009 endpoints — /introspect so a resource server can ask 'is this opaque token still active and what scopes does it carry?', and /revoke so a user or admin can kill a token immediately. This is the answer to the JWT revocation gap from the token milestone: short-lived access JWTs you let expire, plus revocable refresh tokens and opaque tokens you can introspect. The tradeoff is latency — introspection adds a network call per request — so cache active-token results for a few seconds and accept that revocation is eventually-consistent within that window.

Harden the long-lived part of the flow. Implement refresh-token rotation: every refresh call invalidates the old token and issues a new one, so a refresh token is single-use. The payoff is reuse detection — if an already-rotated (consumed) refresh token is presented again, that means either the legitimate client or a thief is replaying it, so you revoke the entire token family and force re-auth. Set a hard refresh-token absolute lifetime (e.g. 14–30 days) and an idle window so abandoned sessions die. On the browser side, store the session in an httpOnly, Secure, SameSite cookie (not localStorage, which any XSS can read), and scope it tightly. The tradeoff: rotation adds write contention on the refresh store and a race when two tabs refresh at once — handle the race with a short grace window or a single-flight lock rather than nuking a legitimate family.

Tie it together with a written threat model and the telemetry to act on it, then survive an incident. Enumerate the flow's attack surface — authorization-code interception, open redirect, CSRF via missing state, token leakage through logs or Referer, and refresh-token theft — and map each to the defense you built. Instrument the auth path with RED metrics (rate, errors, duration on /authorize, /token, /introspect) and structured logs that NEVER record raw tokens, code_verifiers, or client secrets — log a hashed token id at most. Then run the incident: a refresh token leaks (say, it ended up in a server log shipped to a third party). Detect the anomalous reuse from your metrics, revoke the affected token family live, and write a short post-mortem. The real fix is not just 'rotate the leaked token' — it's closing the leak path (redaction, no tokens in URLs) plus rotation so a future leak self-heals on next use.