If you’ve ever Googled “how do I add login with Google,” you’ve bounced between two specs and come away confused. Here’s the shortest possible explanation.
OAuth 2.0 is about authorization
OAuth 2.0 answers the question: can this app act on the user’s behalf? The user grants a client application permission to call a resource server (say, the Google Calendar API) using an access token. OAuth doesn’t care who the user is — it just cares what the app is allowed to do.
That means, technically, OAuth on its own isn’t enough for login. You get an access token, you can call the user’s calendar, but the spec doesn’t give you a standard way to say “and by the way, here’s the user’s identity.”
OIDC is about authentication
OpenID Connect (OIDC) is an identity layer on top of OAuth 2.0. It adds:
- An ID token — a JWT with standardized claims about who the user is (
sub,email,name,picture) - A standardized
/userinfoendpoint for fetching profile data - Well-defined discovery via
/.well-known/openid-configuration
When you “log in with Google,” what you’re actually doing is OIDC. You request the openid scope (and usually profile email), get back an ID token, decode it, verify its signature against Google’s JWKS, and now you know who signed in.
Why this matters in practice
If you’re writing an integration where the goal is “know who the user is,” you want OIDC. That means requesting openid as one of the scopes — without it, you don’t get an ID token and you’re back to guessing identity from the /userinfo endpoint (which works, but is less robust).
If someone in a PR says “we use OAuth for login,” they almost always mean OIDC. Correct the vocabulary once and move on — the terminology trap catches enough junior devs that it’s worth being explicit on your team.
The 30-second rule
Next time you’re picking a protocol:
- Need to call an API on the user’s behalf → OAuth 2.0
- Need to know who the user is → OIDC (which includes OAuth 2.0)
- Both? → OIDC. You get identity and an access token.
That’s the whole decision tree.