OAuth 2.0 and OpenID Connect
A reading-tracker app, ShelfLog, wants to show a member's BookNook loans. The old, bad answer was to ask the member for their BookNook password. OAuth 2.0 lets the member grant ShelfLog limited access, "read my loans", without ever sharing the password, and OpenID Connect adds a way for ShelfLog to learn who the member is.
The rule
OAuth grants access; OpenID Connect proves identity.
OAuth 2.0 has four roles:
- Resource owner: the member, who owns the loan data.
- Client: ShelfLog, the app that wants access.
- Authorization server: BookNook's sign-in service, which asks the member and issues tokens.
- Resource server: the BookNook API, which accepts the tokens.
Access is limited by scopes, named permissions such as loans:read. The member sees exactly what is requested and can refuse.
The recommended flow for apps is the authorization code flow with PKCE:
- ShelfLog sends the member's browser to BookNook's authorization server, asking for
scope=loans:read, with a hashed one-time secret (the PKCE challenge). - The member signs in at BookNook and approves.
- BookNook redirects back to ShelfLog with a short-lived authorization code.
- ShelfLog exchanges the code, plus the original unhashed secret, for an access token (and often a refresh token).
- ShelfLog calls the API with
Authorization: Bearer <token>.
GET /authorize?response_type=code&client_id=shelflog&scope=openid%20loans:read
&redirect_uri=https://shelflog.example/callback&code_challenge=...&state=xyzThe state value lets ShelfLog confirm the redirect answers its own request.
OAuth only says "this token may read loans". It does not define who the user is. OpenID Connect (OIDC) is a thin layer on top: request the openid scope and you also receive an ID token, a JWT with claims like sub (a stable user id), email and name, meant for the client to read. That is what powers "Sign in with..." buttons.
- Access token: for the API. The client should treat it as opaque.
- ID token: for the client, to know who signed in. Do not send it to APIs as an access token.
The shortcut
For any sign-in design, ask two separate questions: "What may this app do?" → OAuth scopes and an access token. "Who is the user?" → OIDC and an ID token.
What may ShelfLog do?
Read loans only: request
scope=loans:read. The member approves it on BookNook's own page.
Drills
Answer fast — trust the rule.
What problem does OAuth 2.0 mainly solve?
In the ShelfLog story, which role does the BookNook API play?
What does OpenID Connect add on top of OAuth 2.0?
ShelfLog should only read loans, never renew them. What limits it?
A developer sends the ID token to the BookNook API as its bearer token. What is wrong?
Remember
- OAuth grants access; OpenID Connect proves identity.
- Shortcut: "what may this app do?" → scopes and access token; "who is the user?" → ID token.
- Trap: sharing passwords with third-party apps, and using ID tokens as access tokens.