OAuth 2.0 and OpenID Connect

When one application needs to reach a user's data held by another, the old answer was to ask for the user's password. OAuth 2.0 replaced that with a token the user approves, limited to certain actions and a certain time, issued by the service that holds the data. OpenID Connect adds the piece OAuth left out: a way for the application to learn who the user is.

The topic opens on the problem OAuth solves and the four roles in every exchange. A walkthrough follows the authorization code flow with PKCE, the flow nearly every application now uses, and a card covers client credentials for a service acting for itself. Scopes and consent come next, then OpenID Connect and its ID token. Two comparisons separate the three tokens and untangle OAuth from JWT. A gotcha explains why two older grants are retired, and an exercise picks a flow for four applications.

It builds on bearer tokens and JWTs from the topic on authenticating API clients.

By the end you can name the four roles, order the code flow with PKCE, choose a grant for an application, tell the access, ID and refresh tokens apart, explain why "OAuth or JWT" is not a choice, and name the flows current guidance rules out.