OAuth 2.0
OAuth 2.0 is the rulebook for getting permission. It answers the question: "what is this app allowed to do?" It lets one application ask a central server for a token that grants limited access to an API — without ever seeing the user's password.
This is the authorization side of things (see Authentication vs Authorization). OAuth is about permission, not identity. "Who are you?" is the job of OpenID Connect (OIDC).
The big idea: the wristband
Think of a token like a pass at a theme park. You trade your ticket (your login) at the gate once, and the park hands you a wristband. You don't pull your ticket out again — you just show the wristband every time you get on a ride. It only gets you into certain rides, and it eventually expires.
- An access token is a short-lived digital pass. A program shows it with every request, and the API checks "is this pass valid, and does it allow this action?"
- The token expires after a while — for safety, so a leaked token is only briefly dangerous.
- A refresh token is a longer-lived pass the program keeps privately, used only to quietly get a new access token when the old one runs out. This way nobody has to type a password again.
The owner of the pass acts — whoever "bears" (carries) it gets in. That's why it's called a Bearer token, and why the header on every request looks like Authorization: Bearer <token>.
The wristband, drawn
The cast — four roles
- Client — an app that wants access (a web app, a mobile app, a headless service). It registers with the server under a Client ID and, for private machines, a Client Secret — basically a username + password for the app itself.
- Resource Owner — the person (or machine) the permissions belong to.
- Authorization Server — the central guard that checks who's allowed and issues tokens.
- Resource Server (API) — the service that actually holds the data; it only ever checks tokens.
Key idea: the API is not the identity server. The API receives tokens and verifies them; the identity server issues them. A client never talks to the API with a password — it proves itself to the identity server, gets a token, then uses that token on the API.
Stateless and central
Because the API only checks tokens (it doesn't keep a list of "who's logged in"), it's stateless and easy to scale — every request is self-contained. And because the password only ever travels through one door (into the identity server), a compromised API doesn't leak anyone's password.
The ways of asking (grant types)
OAuth defines several grant types — different ways a client can prove it deserves a token:
| Grant | Plain meaning | Good for |
|---|---|---|
| Client Credentials | A machine proves itself with its own ID + secret, no user involved | Pure machine-to-machine |
| Password | Presents a username + password | Legacy / one-time bootstrapping |
| Authorization Code | Interactive: a human logs in at a page, then the app trades a code for a token | Web & mobile apps with a real user |
| Device Authorization | A limited device gets a code a human enters elsewhere | TVs, kiosks, IoT |
Each fits a different situation. The kiosk project uses one of these to bootstrap the headless device — see OAuth, OIDC & Duende IdentityModel for the specific design.