OAuth2 & OIDC, Precisely
The four OAuth2 roles, what a grant actually is, and how OpenID Connect adds identity on top - the vocabulary you need before running your own server.
On this page
Back in the Security module, BookVault signed its own HS256 JWTs - a shortcut that works for one app but breaks down the moment a second app, a mobile client, or a partner needs to log in. The real-world answer is OAuth2: a standard protocol for delegating access, with OpenID Connect (OIDC) layered on top for identity. Before you can run your own authorization server, you need the vocabulary exact - most OAuth confusion is really confusion about the four roles.
The four roles
OAuth2 defines four parties. Naming them precisely dissolves most of the mystery:
- Resource Owner - the user who owns the data (a BookVault member).
- Client - the app wanting access on the user's behalf (the BookVault web SPA, a mobile app, a partner integration).
- Authorization Server - the party that authenticates the user and issues tokens (what you'll run this module).
- Resource Server - the API that holds the protected data and accepts tokens (BookVault's REST API).
The whole dance exists so the client can call the resource server on the resource owner's behalf, using a token minted by the authorization server - without the client ever seeing the user's password.
What a "grant" actually is
A grant (or flow) is a defined sequence for the client to obtain a token. Different clients need different flows because they have different trust levels:
- Authorization Code (+ PKCE) - the gold standard for apps where a user logs in: SPAs, mobile, and server-side web apps. The user authenticates at the authorization server, which hands back a short-lived code the client exchanges for tokens. (Next lessons.)
- Client Credentials - no user at all; one service authenticates as itself to call another. Machine-to- machine.
- Refresh Token - exchange a long-lived refresh token for a fresh access token without re-prompting the user.
Two older grants - Implicit and Resource Owner Password Credentials - are now discouraged/removed; authorization code with PKCE replaced both.
OIDC: identity on top of OAuth2
OAuth2 alone is about authorization - "this token may access the catalog." It deliberately says nothing about who the user is. OpenID Connect adds that missing identity layer with three additions:
- An ID Token - a JWT asserting who logged in (subject, name, email), for the client to consume.
- A
/userinfoendpoint - fetch standard profile claims. - Standard scopes -
openid,profile,email.
So the rule of thumb: OAuth2 = access, OIDC = login. When you "Sign in with Google," Google is an OIDC provider - authenticating you (OIDC) and granting the app scoped access to your data (OAuth2).
Access token vs. ID token - don't mix them up
An access token is for the resource server ('let this request through'); an ID token is for the client ('here's who the user is'). Sending an ID token to an API, or reading identity claims off an access token, is a common security mistake. They have different audiences and different purposes - keep them straight.
The authorization server is the front desk: it checks your passport (authenticates you) and issues a key card (access token) that opens only certain doors, plus a printed guest slip with your name (ID token) that staff can read. You (resource owner) never hand your passport to the housekeeping robot (client); it just carries the key card to the room door (resource server), which trusts the card without knowing anything about you. OIDC is the guest slip that adds 'and here's who this guest is' on top of the plain door key.
BookVault's React SPA lets a member view their loans. The member logs in, the SPA calls
GET /api/loans, and a separate nightly reporting service also pulls loan stats from that same API. Map each
of the four OAuth2 roles, and name the grant each of the two clients (SPA and reporting service) should use.
What does OpenID Connect add on top of OAuth2?
Key takeaways
- OAuth2 has four roles: resource owner (user), client (app), authorization server (issues tokens), resource server (the API) - naming them precisely dissolves most confusion.
- A grant is a defined flow to obtain a token; authorization code + PKCE for user login, client credentials for machine-to-machine, refresh token to renew.
- The older implicit and password grants are discouraged/removed; authorization code with PKCE replaced them.
- OpenID Connect adds an identity layer on OAuth2: an ID token (who logged in), a /userinfo endpoint, and standard scopes.
- Access tokens are for the resource server (access); ID tokens are for the client (identity) - never mix their audiences.