Status
This minisite is under construction. What you see now is the real scaffold: a primer on RFC 6749, a working PKCE playground, and the briefing's listening room, with the deeper flow-by-flow writing to follow. Nothing here is a placeholder.
The flows
OAuth2 is best understood one grant type at a time. Each flow gets its own deep dive: where it fits, the exact requests on the wire, and the ways it goes wrong in production.
- Authorization code + PKCE. The flow behind "Sign in with ..." buttons and modern SPAs. Primer is live:RFC 6749 and the authorization-code grant.
- Client credentials. Machine-to-machine auth with no user in the loop. coming
- Device authorization. Signing in on TVs, consoles, and anything with no good keyboard. coming
The specs
The RFCs that actually matter, translated into plain English and diagrams - without losing the normative details you need to implement against.
- RFC 6749. The OAuth2 framework itself, and the grant every other document builds on. Read the primer.
- RFC 7636 (PKCE). Proof key exchange that keeps the authorization code from being hijacked. Try the playground.
- RFC 6750. Bearer tokens: how access tokens are presented, and why "just put it in the header" has fine print. coming
- RFC 8252. OAuth2 for native apps, loopback redirects and all. coming
Playgrounds
Reading about cryptography is not understanding it. Each playground runs in your browser with real primitives - no server, nothing leaves the page.
- PKCE playground.Generate a code verifier and its S256 challenge with WebCrypto, exactly as your app would before sending a user to the authorize endpoint.
- JWT decoder and more as the deep dives land. coming