ndovu
Which grant fits your app?
A grant type is how a client gets an access token. OAuth2 has four surviving core grants, one extension, and two retired ones; picking between them is two or three questions. Answer them here, or compare every grant in the table below.
| Grant | Built for | User approves? | Client type | Token lands | Refresh? |
|---|---|---|---|---|---|
| Authorization code the default6749 §4.1 · +PKCE 7636 | Web apps, SPAs, native apps - every "Sign in with ..." | Yes, at the AS | Confidential or public | Back channel (only the code crosses the browser) | Yes |
| Client credentials current6749 §4.4 | Machine-to-machine: services, daemons, CI, batch jobs | No - the client acts as itself | Confidential | Back channel | No (re-requests instead) |
| Device authorization current8628 (2019) | TVs, consoles, streaming sticks, CLIs, kiosks | Yes, on a second device | Public (typically) | Back channel (device polls) | Typically |
| Refresh token current6749 §6 | Renewing access without the user present | No | Any client that holds one | Back channel | - |
| Token exchange extension8693 (2020) | Delegation and impersonation: swapping one credential for another | No - the credential carries the authority | Confidential | Back channel | - |
| Implicit retired6749 §4.2 | 2012-era browser apps without a backend | Yes, at the AS | Public | Front channel (URL fragment) | No |
| Resource owner password retired6749 §4.3 | First-party apps the AS trusts with raw passwords | Types their password into the client | Confidential (typically) | Back channel | Allowed |
"Front channel" = values that ride through the user's browser; "back channel" = direct client-to-server calls over TLS. The deep dives draw this distinction on every diagram. "AS" = authorization server, the service that authenticates the user and issues tokens. "Extension" marks a grant defined outside the core framework: token exchange is RFC 8693, covered with the modern suite.
The grants, one deep dive each
Every flow gets the full treatment: where it fits, the exact requests on the wire with annotated parameters, the security properties it does and does not give you, and the ways it goes wrong in production.
- Authorization code.The flow behind every "Sign in with ..." button, and the one every other document builds on. Includes refresh tokens and the PKCE variant.
- Client credentials.Machine-to-machine auth with no user in the loop - and the client authentication methods that decide whether it is actually secure.
- Device authorization.Signing in on TVs, consoles, and anything with no good keyboard: the two-screen flow, the polling rules, and its phishing caveats.
- The retired grants.Implicit and resource-owner-password: what problems they solved in 2012, the failures that killed them, and what replaced them.
The specs, translated
The RFCs that actually matter, translated into plain English and diagrams - without losing the normative details you implement against. Every claim carries its section number.
- RFC 6749 - the framework.The 2012 document that defines OAuth2: four roles, two endpoints, client types, token semantics, and the error codes every grant reuses.
- OAuth 2.1 and the modern suite.The consolidation in progress - and the extensions that carry today's real workloads: token exchange, DPoP, PAR, JWT access tokens.
- RFC 6750 - bearer tokens.How access tokens are presented, the fine print on each method, and the WWW-Authenticate errors a resource server owes you.
- RFC 8252 - native apps.OAuth on phones and desktops: loopback redirects, private-use URI schemes, and why embedded webviews lost.
- RFC 9068 - JWT access tokens.The interoperable layout for self-contained access tokens: at+jwt typing, the required claims, and the validation checklist - run live in the JWT inspector.
- RFC 10017 - browser-based apps.The newest BCP, for SPAs: the malicious-JavaScript threat model, the architecture ranking that answers it, and what browser token storage can and cannot buy.
- RFC 9449 - DPoP.Sender-constrained tokens for SPAs and native apps: the signed proof JWT, the cnf/jkt binding, the nonce, and the mTLS comparison.
- RFC 7636 (PKCE). Proof-key exchange that makes a stolen authorization code worthless - covered end to end in the PKCE console.
Consoles and audio explainers
Reading about a mechanism is not understanding it. Each console runs the real thing in your browser - genuine keys, real checks, and tamper buttons that let you attack each defense and watch it hold.
- The PKCE console.Run the entire authorization-code + PKCE flow: keys, redirect, sign-in, state check, token exchange - with tamper buttons on every defense.
- The device console.Run the two-device dance end to end: the TV shows a code, your phone approves, the device polls - with the exact slow_down rule, expiry, and the remote-phishing twist.
- The JWT inspector.Paste or mint a token and watch a resource server think: header policy, key selection, a real signature check, claims policy - with six tamper buttons that teach both classes of failure.
The mechanisms spoken, each with a read-along transcript in the listening room.