TL;DR: OAuth 2.0 is delegated authorization: it gives a client an access token to call an API on a user's behalf. OpenID Connect adds authentication: with the
openidscope the client also receives an ID token, a signed JWT stating who the user is, issued for that client (aud), with expiry and anonce. ID tokens are for the client to establish a login; access tokens are for APIs. Using one as the other causes account takeover and replay bugs.
How to approach it
Contrast purpose, audience and format for the two tokens, then show the two classic confusions as concrete attacks. End with the validation checklist for ID tokens.
A strong answer
Access token (OAuth)
Client
carries it
API
the audience
Checks scope and audience
Outcome, safe: Delegated authorisation
Says what the client may do, not who the user is
ID token (OpenID Connect)
Auth server
signs it
Client
the audience
Checks iss, aud, exp, nonce
Outcome, safe: Authentication of the user
Never send it to APIs as a credential
| ID token (OIDC) | Access token (OAuth) | |
|---|---|---|
| Question it answers | Who logged in to this client? | May the bearer call this API? |
| Audience | The client (aud = client ID) | The resource server |
| Format | Always a signed JWT | Opaque or JWT; clients should treat it as opaque |
| Consumed by | The client, once, to create a session | APIs, on every call |
| Key claims | iss, sub, aud, exp, iat, nonce, optionally acr/amr | Scopes, audience, expiry (format varies) |
Confusion 1: login with an access token. An app accepts any valid access token from the provider and calls the profile endpoint to identify the user. A malicious app that integrates with the same provider can replay its users' access tokens to this app and log in as them, because the access token was never meant to prove identity to this app. The fix is OIDC: validate an ID token whose aud is your client ID.
Confusion 2: APIs that accept ID tokens. An API treats ID tokens as bearer credentials. Any client the user has logged into holds an ID token for that user and could call the API with it. APIs should accept access tokens issued for them, checked by audience and scope.
Validating an ID token. Verify the signature with keys from the provider's JWKS endpoint using an algorithm fixed in configuration; check iss exactly; check aud contains your client ID (and azp if multiple audiences); check exp and iat; check nonce matches the one stored for this login; and key the account on iss plus sub, never on email alone.
After validation. Create the application's own session (an HttpOnly cookie); do not keep re-sending the ID token. Use the refresh token or re-authentication for longer sessions.
What interviewers probe next
- "Can the client read claims from the access token?" It should not rely on them; the format belongs to the authorization server and API and may change or be encrypted.
- "Why key accounts on sub rather than email?" Emails change, can be reassigned and are sometimes unverified;
subis stable per issuer. - "How does SAML compare?" Same goal as OIDC for enterprise SSO, using signed XML assertions; similar validation pitfalls around audience, signatures and replay.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A team uses an OAuth access token from Google to decide who is logged in to their web app, by calling a profile API with it.
Start here
What is the difference between OAuth and OpenID Connect?
Which token is meant to identify the user?
OAuth 2.0 is delegated authorisation: it gives a client an access token to call an API for a user. OpenID Connect adds authentication: with the openid scope, the client also gets an ID token, a signed JWT saying who the user is, issued for that client, with expiry and a nonce.
Carry it forwardOAuth authorises API calls; OIDC authenticates users.
Weak answerTreating any access token as proof of login.
Constraint changes
Why is using an access token as login proof dangerous?
Was the token issued for your app?
An access token issued to another app for the same provider can be presented to yours, and the profile API will happily return the user's identity. An attacker who gets a victim to log into a malicious app can then log into your app as the victim.
Carry it forwardAccess tokens do not prove which client they were issued to.
Weak answerCalling a profile endpoint as authentication.
Constraint changes
What should the app check on the ID token?
Which claims tie the token to your app and this login?
The signature with the provider's keys, the issuer, that the audience is your client ID, expiry, and the nonce you sent. Then use the stable subject identifier, not the email address, to identify the account.
Carry it forwardVerify signature, iss, aud, exp and nonce.
Weak answerDecoding the ID token without verifying it.
Constraint changes
What if the app links accounts by email address?
Is an email address a stable, unique identity?
Emails can change, be reused or be unverified at some providers, which can let one person claim another's account. Use the issuer plus subject as the identity key, and only link by email when the provider marks it verified and the user confirms.
Carry it forwardIdentify users by issuer and subject.
Weak answerMerging accounts on matching emails.
Constraint changes
What should access tokens be used for, then?
Who is the audience of each token?
Calling APIs, with each API checking the token's audience and scopes. Keep the two jobs separate: ID tokens establish the login in your app; access tokens authorise API calls.
Carry it forwardID tokens for login, access tokens for APIs.
Weak answerSending ID tokens to APIs as bearer tokens.
Now defend it
How would you fix the login?
Use OpenID Connect: request the openid scope, verify the ID token's signature, issuer, audience equal to your client ID, expiry and nonce, identify users by issuer plus subject, link accounts by email only when verified and confirmed, and use access tokens only to call APIs that check their audience.
How it's scored
Weak: Says OIDC and OAuth are the same, or that the ID token is used to call APIs.
Hire: Distinguishes authorization from authentication and the two tokens' audiences correctly.
Strong Hire: Explains both confusion attacks, gives the full ID token validation list, and keys accounts correctly.
Common mistakes
- Implementing "login" with OAuth access tokens alone.
- Skipping the
audornoncecheck. - Accepting the token's
algheader instead of a configured algorithm. - Linking accounts across providers by email.