The difference between OIDC and OAuth 2.0 is what they’re for: OAuth 2.0 is an authorization framework that grants apps access to resources, while OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0 that verifies who the user is. In short, OAuth answers "what can this app access?"; OIDC answers "who is this user?"

They’re constantly confused because OIDC is built on OAuth and they share flows and terminology. But using the wrong one causes real security problems, so the distinction is worth getting right.

The core distinction

• OAuth 2.0 = authorization. It lets a user grant an app scoped access to their resources (your calendar, your files) without sharing a password. It issues access tokens for resources.
• OIDC = authentication. It lets an app verify the user’s identity through a trusted provider. It adds the ID token, a signed assertion of who the user is.

OIDC uses OAuth’s machinery and adds the identity piece OAuth lacks.

Why using OAuth alone for login is a mistake

A common anti-pattern is using raw OAuth 2.0 to "log users in." The problem: an OAuth access token proves the app was granted access to some resource, not who the user is. Relying on it for authentication leads to subtle vulnerabilities (for example, token-substitution attacks where a token issued for one app is misused by another). OIDC was created specifically to fix this by providing a proper, verifiable identity assertion (the ID token) with the right validations (audience, issuer, nonce). If you need login, use OIDC, not OAuth alone.

When to use each

• Use OAuth 2.0 when an application needs delegated access to resources or APIs on the user’s behalf, "let this app post to my social account," or machine-to-machine API access.
• Use OIDC when an application needs to authenticate the user and know their identity: "sign in with," SSO, or any login scenario.
• Use both together in the common case where an app both logs the user in (OIDC) and accesses resources on their behalf (OAuth), OIDC’s flow yields both an ID token and an access token.

The bottom line

Think of OAuth as valet keys for your resources and OIDC as an ID card for the user. They complement rather than compete: OIDC is OAuth plus identity. Choosing correctly (OIDC for authentication, OAuth for resource authorization, both when you need each) is fundamental to building secure, standards-based applications.

Frequently asked questions

What’s the main difference between OIDC and OAuth 2.0?

OAuth 2.0 authorizes resource access; OIDC authenticates the user’s identity on top of OAuth.

Can I use OAuth 2.0 for login?

You shouldn’t use it alone, OAuth proves resource access, not identity. Use OpenID Connect for authentication.

Do OIDC and OAuth work together?

Yes, a single OIDC flow can return both an ID token (identity) and an access token (resource access).

Which should I use for "sign in with"?

OIDC, since it provides a verifiable identity assertion; OAuth alone lacks proper authentication.

Is OIDC built on OAuth?

Yes, OIDC is an identity layer on top of OAuth 2.0, reusing its flows and adding the ID token for authentication.

What token does each produce?

OAuth issues an access token (for resources); OIDC additionally issues an ID token (for identity).

Related: OAuth 2.0 · OpenID Connect (OIDC) · Authentication vs. Authorization · Single Sign-On (SSO) · Identity Provider (IdP)