01 The Problem

A calendar-scheduling app wants to read events from a user's Google Calendar to suggest meeting times. The obvious approach: ask the user for their Google email and password, log in as them directly. Now the scheduling app has the user's actual password, can do anything the account allows, read every email, change account recovery settings, not just read calendar events, and there's no way to revoke just the calendar access without changing the password everywhere else that app might have cached it.

What's actually needed: the user grants the scheduling app permission to read calendar events specifically, the app never sees a password, and the permission can be revoked later without touching the user's actual credentials at all.

A separate issue shows up right next to it. A lot of apps also want to know who the user is, so they can create an account or skip a signup form, "Sign in with Google." That's a different question from "can this app read my calendar," but the mechanism answering it, redirect to Google, come back with a token, ended up built on the exact same protocol as the calendar-access case. Two different questions, answered by the same-looking flow, is where the confusion starts.

OAuth answers the first question, delegated permission. OpenID Connect answers the second, identity, layered directly on top of OAuth's mechanics. Confusing them is confusing "this app can act on your behalf" with "this app knows who you are," and a system that only checks one when it needed the other has a real security gap, not a naming nitpick.

02 What It Is

OAuth 2.0 is a delegated authorization protocol. A user, through their browser, grants a third-party app a scoped permission, a "scope," like calendar.read, without giving the app their password. The app ends up with an access token, a credential proving "this token is allowed to do X, on behalf of this user, at this provider," and that token is what the app presents to the provider's API on every subsequent request. The access token says nothing about who the user is. It's not an identity document, it's a permission slip.

OpenID Connect (OIDC) is an identity layer built on top of OAuth. It adds a specific kind of token, an ID token, which is about identity, a signed, verifiable claim of who the user is, typically a JWT. The rest of the flow, the redirect, the consent screen, the token exchange, is the same OAuth machinery. OIDC just adds this one token type and a specific set of claims. That reuse is exactly why the two get conflated: an app doing "Sign in with Google" and an app that got permission to read your calendar go through a visually identical flow, but one ends with an identity claim, the other with a permission grant.

The actual hard part isn't implementing either protocol, both have mature, well-tested libraries. It's knowing which one is actually being implemented, and checking the right token for the right question. Using an OAuth access token to answer "who is this user" is a common, real mistake. Access tokens aren't required to be interpretable by the app at all, some providers hand back an opaque string, and even a readable one carries no guaranteed claim of identity the way an OIDC ID token does.

In Plain Terms

Handing a valet your car key with instructions to park it only, versus handing someone your driver's license to prove who you are, are two different acts even though both involve handing over a small plastic object at a counter. A valet key that starts the car proves you authorized parking, nothing about who's standing there. A license proves identity, nothing about what they're allowed to do with your car. Treating the valet key as identification because someone at the counter accepted it works fine right up until it doesn't.

03 How It Works

Rendering diagram…

Rendering diagram…

04 Trade-offs

	OAuth access token	OIDC ID token
What it proves	This app is allowed to do X, on this user's behalf, at this provider	This person is who they claim to be, verified by the provider
Format	Opaque or structured, provider's choice, not guaranteed to be readable by the app	Typically a JWT, meant to be decoded and verified by the app directly
Used for	Calling the provider's API on the user's behalf	Establishing a session or account for the user in the app itself
Common mistake	Treating it as proof of identity, which it was never designed to guarantee	N/A, this is the token actually built for that question

05 Where You'll Actually See This

Neither case study implements authentication, so neither shows OAuth or OIDC directly. Worth naming: the moment either needed a third party acting on a user's behalf, a customer authorizing a separate app to initiate payments for them, say, this exact delegated-permission shape is what that requires, not a shared password.

Authentication vs authorization is the general version of the split this article is a concrete, standardized instance of. OIDC's ID token is authentication, who this is. OAuth's access token is authorization, what this app can do. The confusion this article covers is the same confusion that article covers, just with real protocol names and a spec behind it.

JWT & Sessions is directly relevant to the ID token specifically: OIDC's ID token is typically a JWT, which means it inherits everything that article covers, a local signature check with no lookup required, and the same revocation problem. An ID token issued before a user's account was compromised is still a valid, verifiable claim of identity until it expires, for the same reason any other JWT is.

None of this matters if the redirect and token exchange this article describes happens over plain HTTP. Encryption and TLS is the assumption underneath the whole flow: an access token or an ID token intercepted in transit is just as usable to an attacker as one obtained by tricking the consent screen, and no amount of careful scoping or revocation design helps a token that was handed to an eavesdropper before it ever reached the app.

How to reason about it

When asked to explain OAuth versus OIDC, don't just say "OIDC is built on top of OAuth." Say what each token actually proves: an access token proves a scoped permission was granted, an ID token proves who the user is. An answer that doesn't name which specific token to check for a "who is this user" question has described the relationship between the two protocols without describing how to actually use them correctly.

06 Quick Check