OAuth 2.0 vs OpenID Connect: What's the Difference?

OAuth 2.0 and OpenID Connect are constantly confused, and using the wrong one creates real security holes. The short version: OAuth is for authorization, OIDC is for authentication.

OAuth 2.0 is about access, not identity

OAuth 2.0 lets an application get delegated access to resources on a user's behalf, for example "let this app read my calendar." It issues access tokens scoped to permissions. Crucially, OAuth was never designed to tell you who the user is, and using an access token as proof of login is a classic mistake.

OpenID Connect adds identity

OIDC is a thin layer on top of OAuth 2.0 that adds an ID token (a signed JWT) describing the authenticated user and a standard userinfo endpoint. When you need to log a user in, you want OIDC.

A simple rule

• "Log this user in" → OIDC.
• "Let this app act on the user's resources" → OAuth 2.0.
• Securing machine-to-machine or AI agents? See non-human identity and our authorization category.

Why the confusion causes real bugs

Two failure modes account for most of the damage:

Using an access token as proof of identity. An access token says a client was authorized for some scope. It does not say who the user is, and in many designs it is not audience-restricted to your application. Accepting one as a login credential lets a token minted for a different application authenticate against yours. Use the ID token for authentication and derive your own session from it.

Sending an ID token to an API. The mirror image, and just as common. ID tokens are for the client, meant to be validated once at sign-in. Resource servers should receive access tokens. Sending an ID token to an API usually means the API is validating the wrong audience, or not validating at all.

The current best practice

OAuth 2.1 consolidates a decade of security guidance into defaults worth adopting even if you stay on 2.0:

• Authorization code with PKCE for every client, confidential ones included. There is no reason to omit it in new code.
• No implicit flow. Returning tokens in the redirect puts them in URLs, browser history, and referrer headers.
• No resource owner password grant. It requires the application to handle credentials, which is the thing OAuth exists to avoid.
• Exact redirect URI matching, not prefix or wildcard.
• Rotate refresh tokens on use and detect reuse of a spent token, which is the signal that a copy is circulating.

Where OAuth is heading

Bearer tokens are the last large replay hole, which is why sender-constraining is gaining ground: DPoP binds a token to a key the client proves possession of, and mTLS does the same where you control the transport. The 2026 work on AI agent authorization builds on the same machinery, with token exchange narrowing scope at each hop in a delegation chain.

Where to start

Where to start

Read the OAuth 2.0 and OIDC implementation guide, and the related SAML vs OIDC comparison.