What Is OpenID Connect? OIDC vs OAuth Explained

I shipped a "Sign in with Google" button once and told my team it was OAuth. A reviewer left exactly one comment on the pull request: "Where are you validating the ID token?" I didn't have one. I was reading the user's email out of an access token I wasn't even verifying, and calling that a login. That comment was my real introduction to OpenID Connect — and to a distinction that a surprising number of shipped auth flows get wrong.

So let me save you the code-review embarrassment and walk the difference from the gap it exists to fill.

The gap OAuth leaves open

OAuth 2.0 is a delegation framework. Its whole job is to let an app do something on your behalf — read your calendar, post to your feed — without you handing over your password. If that's fuzzy, what is OAuth covers the four roles and the token dance in full. The important thing here is what OAuth deliberately does not do: it never tells the app who you are. It grants a scoped, expiring access token that says what the app may do, and stops there.

That's a feature, not an oversight. "Let this app read my photos" genuinely doesn't require the app to know your name. But it leaves a hole the moment you want to log in with an existing account, because now identity is the entire point — and OAuth alone won't give it to you in any trustworthy form. (In the enterprise world the older answer to that same need is SAML; SAML vs OIDC compares the two federated-login approaches head to head.)

The shortcut that quietly breaks

Here's the trap I fell into, and it's an easy one. After an OAuth flow you're holding an access token, and many providers let you call a userinfo-style endpoint with it to fetch the account's email and name. So you do that, read the email, and treat the user as logged in. It even works in the demo.

The problem is subtle: an access token is a capability, not a statement of identity. It's designed to be handed to APIs, it can be issued to a different application than yours, and depending on the flow you may have no cryptographic guarantee about who it really belongs to or which app it was minted for. Building login on top of it is like accepting a valet parking ticket as someone's passport — it's the wrong document for the question you're asking. This class of confusion is a well-known source of authentication bugs.

What OIDC adds: the ID token

OpenID Connect closes that hole with one clean addition: the ID token. When you request login (by adding the openid scope to an otherwise ordinary OAuth authorization-code flow), the provider returns, alongside the access token, a second token whose entire purpose is to say who authenticated. It's a JSON Web Token — a signed JWT — and being signed is the point: your app can verify it came from the provider and hasn't been altered, without a network call back to ask.

That's the OIDC bargain in one line. OAuth already knew how to hand out tokens after a user approves an app; OIDC just defines one more token, with a standard shape, that answers the identity question OAuth left on the table. The "Sign in with Google" feeling everyone attributes to OAuth is really this — a thin identity standard riding on OAuth's rails.

What's actually inside an ID token

Decode an ID token and you'll find a predictable set of claims, each doing a validation job:

• sub — the subject: a stable, unique ID for the user at that provider. This, not the email, is the thing you key your accounts on (emails change and get reassigned).
• iss — the issuer: which provider minted the token. You check it matches the provider you actually integrated.
• aud — the audience: the client ID this token was issued for. If it's not your app, reject it — this is the check that stops a token meant for someone else being replayed at you.
• exp and iat — expiry and issued-at timestamps, the same lifetime mechanics as when a JWT expires.
• nonce — a value your app generated and sent into the flow, echoed back so you can confirm this token answers your login request and isn't a replay.
• Often email, name, and picture for a friendly profile — convenient, but the trustworthy identifier is still sub.

You can paste a real ID token into the JWT Decoder to see these claims laid out, and check its lifetime with the JWT Expiration Checker. Just remember decoding is not verifying — the decoder shows you the contents, but your server still has to validate the signature and those claims before believing a word.

ID token vs access token: don't cross the streams

This is the single most useful thing to hold onto, because getting it wrong is what my reviewer caught:

• The ID token is for your app to read. It answers "who is this user," you validate it once at login, and you generally don't send it anywhere else.
• The access token is for a resource server to receive. It answers "what may this app do," and it rides to APIs in the Authorization: Bearer header — the Bearer Token Parser is what pulls it back out of that header on the receiving side.

Send an ID token to an API as a credential, or trust an access token as proof of identity, and you've mixed up two documents with different audiences and different jobs. Different from either is a static API key — an app-level secret with no user identity attached at all, generated with an API Key Generator — which is worth contrasting so you don't reach for the wrong credential model entirely.

Validate before you trust

The protocol is only as safe as your validation, so the checklist is the security: verify the ID token's signature against the provider's published keys, confirm iss is the provider you expect, confirm aud is your client ID, confirm it hasn't expired, and confirm the nonce matches the one you sent. Every OIDC-certified library does this for you — the right move is to use one, not to hand-roll JWT parsing and skip a step. My original bug wasn't a flaw in OpenID Connect; it was me never running these checks because I didn't know the ID token existed.

The takeaway

OpenID Connect is the identity layer OAuth doesn't include: a small standard that adds a signed ID token so an app learns who the user is, in a form it can verify, while still using OAuth to handle what the app may do. Keep the two tokens in their lanes — ID token for your app to validate at login, access token for APIs — validate every ID token's signature and claims before trusting it, and key users on sub, not email. Get that straight and "Sign in with Google" stops being magic and becomes a checklist you can actually secure.