Overview
These two get confused because one is built on the other and they share every moving part: the same authorization server, the same redirect dance, the same token endpoint. The distinction is what question each answers. OAuth 2.0 answers "is this application allowed to access this resource?", delegated authorization, letting an app call an API on a user's behalf without ever seeing their password. OpenID Connect (OIDC) answers "who is this user?", authentication, a thin identity layer on top of OAuth 2.0 that adds a signed ID token proving who logged in, when, and how.
Put differently: OAuth 2.0 gets an app access to your calendar. OIDC is what "Sign in with Google" actually is.
Feature comparison
| OAuth 2.0 | OpenID Connect | |
|---|---|---|
| Purpose | Authorization (delegated API access) | Authentication (verified user identity), on top of OAuth 2.0 |
| Defined by | IETF (RFC 6749, 6750, and successors) | OpenID Foundation (OIDC Core 1.0) |
| Key token | Access token, opaque to the client, meant for the API | ID token, a JWT the client itself validates (iss, sub, aud, exp, nonce) |
| Says who the user is | No; an access token proves permission, not identity | Yes; that's the point |
| Standard user info | None; every provider invents its own /me endpoint | UserInfo endpoint and standardized claims (sub, email, name, …) |
| Scopes | Free-form, API-defined (repo, calendar.read) | Reserved scopes: openid (required), profile, email, … |
| Discovery | Not standardized in the core spec | /.well-known/openid-configuration metadata document |
| Session concepts | None | Optional single sign-on, session management, and logout specs |
| Typical use | Third-party API integrations, service-to-service access | Login, SSO across apps, identity federation |
Where plain OAuth 2.0 is the right tool
When identity isn't the question. A CI system pushing to a Git host, a backend calling a partner API with the client-credentials grant, or a user granting a scheduling app write access to their calendar, none of these need an ID token, because nobody is logging in to anything. The access token's job is purely to carry permission to the resource server, and the client treats it as an opaque string.
Where OpenID Connect is the right tool
Any time you're building login. OIDC exists because people bent OAuth 2.0 into an authentication system by fetching a profile from some provider-specific endpoint with an access token, and that improvisation was subtly broken: an access token doesn't say who the user is, when they authenticated, or that it was even issued for your app. The ID token fixes all of that with a signed, audience-bound, replay-protected assertion the client validates itself, plus standardized claims, discovery, and SSO semantics that work the same across every compliant provider.
Warning
Never accept a bare OAuth access token as proof of identity. A token issued to a different, possibly
malicious app for the same API can be replayed to your "login" endpoint and pass, because access
tokens aren't audience-bound to your client. This is exactly the hole OIDC's ID token (with its
aud and nonce checks) closes; if you're verifying users, require it.
Verdict
This isn't a competition, it's a layering: OIDC is OAuth 2.0 plus identity. Use plain OAuth 2.0
when an application needs delegated access to an API and the user's identity is irrelevant to
your system. Use OpenID Connect the moment the words "sign in" appear in your requirements. In
practice most modern identity providers speak both from the same endpoints, add the openid
scope and you're doing OIDC, so the real decision is not which protocol to deploy but which token
you trust for which claim: access tokens for permission, ID tokens for identity.