Separate OAuth from login

OAuth lets a client obtain delegated access to a protected resource. OpenID Connect adds an identity layer for authentication.

Use a provider’s documented OIDC flow when the product goal is “sign in.” Validate tokens for the intended issuer, audience, signature, and lifetime. Do not invent identity meaning from an arbitrary OAuth access token.

Imagine a calendar application asking permission to read your events. OAuth answers: “May this client call the calendar API with this scope?” It does not, by itself, define how your application should identify the person.

OIDC adds an ID token and standardized identity claims. The authorization server issues that token to a specific client after an authentication flow.

Keep artifacts in their lanes:

• the authorization code is short-lived and exchanged once
• the ID token describes an authentication event for the client
• the access token authorizes calls to its resource server
• the refresh token obtains new tokens and needs stronger storage controls

Do not send a provider access token to an unrelated API and call the response “logged in.” Its audience, scopes, and validation rules belong to the resource server it was issued for.

Use a maintained OIDC library. Discovery, key rotation, signature algorithms, nonce, issuer, and audience validation are protocol work, not application string parsing.

Draw the browser, Books app, authorization server, and resource server for a federated login. Label each artifact, its audience, and the component allowed to receive it.