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

Source: https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/
Last updated: 2026-08-29
License: content by Start with Identity. Cite the source URL.

---

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](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/) and our [authorization](https://startwithidentity.com/vendors/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](https://startwithidentity.com/glossary/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](https://startwithidentity.com/glossary/access-token/). 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](https://startwithidentity.com/glossary/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](https://startwithidentity.com/glossary/refresh-token/) 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](https://startwithidentity.com/glossary/dpop/) binds a token to a key the client proves possession of, and [mTLS](https://startwithidentity.com/glossary/mtls/) does the same where you control the transport. The 2026 work on AI agent authorization builds on the same machinery, with [token exchange](https://startwithidentity.com/glossary/token-exchange/) narrowing scope at each hop in a delegation chain.

## Where to start

Read the [OAuth 2.0 and OIDC implementation guide](https://startwithidentity.com/guides/implementation/oauth-2-openid-connect-implementation/), and the related [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/) comparison.