OAuth 2.0 / JWT
OAuth 2.0 is a 4-actor dance: User, Client, Authorization Server, Resource Server. The animation walks through redirect → user-authn → auth-code → token-exchange → JWT-issued → resource-access. Chips render in signal-amber tint during the pre-issuance phase, then flip to instrument-cyan once the JWT is issued (sanctioned flow-stage tint exception).
Animation
Engineering pitfalls
Redirect URI not exact-match
OAuth 2.0 requires exact-match redirect URIs. Adding a path or query parameter mismatch = `invalid_redirect_uri`. Register every legitimate URI explicitly; never accept wildcards.
JWT signature algorithm confusion (alg: none)
Some old JWT libraries accept `alg: none` headers — meaning unsigned tokens are trusted. Always allowlist your accepted algorithms (RS256, ES256) and reject `none`.
PKCE absent for public clients
OAuth 2.0 public clients (SPAs, mobile apps) MUST use PKCE. Without it, an attacker who intercepts the auth-code can exchange it for tokens. PKCE is mandatory in OAuth 2.1.
References
Primary sources
- RFC 6749 — The OAuth 2.0 Authorization Framework.
- RFC 7519 — JSON Web Token (JWT).
- RFC 7636 — Proof Key for Code Exchange by OAuth Public Clients (PKCE).