Part 1 · 2 chapters · ~12 min

OAuth 2.1 and OpenID Connect Flows

What OAuth is (delegated authorisation) and is not, the authorisation code flow with PKCE, client credentials for machines, the device flow, refresh tokens and rotation, scopes and consent, OpenID Connect ID tokens and discovery, and the flows OAuth 2.1 removed.

3

The code flow with PKCE

OAuth lets a client act on a user's behalf with limited permission (scopes) without the user's password. OpenID Connect adds authentication on top: an ID token that says who the user is, a userinfo endpoint and discovery (/.well-known/openid-configuration).

AUTHORISATION CODE FLOW WITH PKCE
how an app gets tokens without ever seeing the password
userapp (client)authorisation serverresource APIverifier = random; challenge = SHA256(verifier)/authorize?code_challenge=…&state=…
swipe the figure sideways, or tap expand for full screen
1/4
PKCE
The app creates a random code verifier and sends only its hash (code challenge) in the authorisation request. A stolen authorisation code is useless without the verifier.
hash in the request, secret kept backmandatory in OAuth 2.1 for all clients
4

Other flows, refresh tokens and what 2.1 removed

flowuse
authorisation code + PKCEevery user-facing app: web, mobile, SPA (via a BFF ideally)
client credentialsa service acting as itself (no user): batch jobs, service-to-service
device authorisationTVs, CLIs: show a code, user approves on their phone
refresh tokenrenew access tokens; rotate on every use and detect reuse (reuse = theft: revoke the family)
token exchange (RFC 8693)a service swaps a user token for a narrower one to call downstream
removed in 2.1: implicit, password granttokens in URLs and apps handling passwords were the problem

ID token versus access token: the ID token is for the client (who logged in); the access token is for the API (what may be done). Never send ID tokens to APIs as access tokens, and never use access tokens to establish the user's identity in the client.