The Core Confusion: Authorization vs. Authentication

Developers frequently use OAuth 2.0 and OpenID Connect interchangeably, but they solve fundamentally different problems. Understanding the distinction isn't just academic — it determines whether your application is secure and correctly implemented.

  • OAuth 2.0 is an authorization framework. It answers: "Can this app access this resource on behalf of a user?"
  • OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0. It answers: "Who is this user?"

How OAuth 2.0 Works

OAuth 2.0 defines how a client application can obtain limited access to a resource server on behalf of a resource owner (typically the user). The key output of an OAuth 2.0 flow is an access token — a credential that grants the client permission to call APIs.

OAuth 2.0 defines four core grant types:

  1. Authorization Code — Redirect-based flow for server-side and SPA apps. The most secure and widely recommended.
  2. Client Credentials — Machine-to-machine flows with no user involved.
  3. Device Code — For input-constrained devices like smart TVs.
  4. Implicit — Deprecated. Do not use in new applications.

Critically, OAuth 2.0 access tokens do not carry identity information about the user. They only grant permissions. This is where many developers go wrong — treating an access token as proof of identity.

How OpenID Connect Extends OAuth 2.0

OpenID Connect uses the OAuth 2.0 Authorization Code flow but adds a second token: the ID token. The ID token is a JSON Web Token (JWT) that contains standardized claims about the authenticated user, such as:

  • sub — A unique subject identifier for the user
  • email — The user's email address (if requested)
  • name — The user's display name
  • iat / exp — Token issued-at and expiry timestamps
  • iss — The issuer (identity provider URL)
  • aud — The intended audience (your client ID)

OIDC also defines a UserInfo endpoint that clients can call with the access token to retrieve additional user claims.

Side-by-Side Comparison

Feature OAuth 2.0 OpenID Connect
Purpose Authorization (access control) Authentication (identity verification)
Primary token Access token ID token (+ access token)
Token format Opaque or JWT Always JWT
User info Not defined Standardized UserInfo endpoint
Use case API access delegation Single sign-on, login flows

When to Use Which

Use OAuth 2.0 alone when:

  • Your app needs to call a third-party API (e.g., GitHub, Google Drive) on behalf of users.
  • You're building a service-to-service integration with no user context.
  • You don't need to know who the user is — only that they granted permission.

Use OpenID Connect when:

  • You're building a login system and need to identify the user.
  • You want to implement Single Sign-On (SSO) across multiple applications.
  • You need a standardized way to obtain user profile information.

The Bottom Line

Think of it this way: OAuth 2.0 gives your app a key card to enter certain rooms. OpenID Connect tells you whose key card it is. For most modern web applications that need both user login and API access, you'll implement OpenID Connect — which automatically gives you OAuth 2.0 underneath.

Never use an OAuth 2.0 access token as a substitute for authentication. Always reach for OIDC when identity matters.