Backend Study Lab

Backend

OAuth 2.0 vs OpenID Connect

Compare OAuth 2.0 and OpenID Connect for backend developers, including authorization, login, ID tokens, access tokens, scopes, and common mistakes.

By CloveCode Studio Jun 29, 2026 Updated Jun 29, 2026 5 min read

OAuth 2.0 and OpenID Connect are often discussed together because they appear in the same login screens and identity provider dashboards. They are not the same thing.

OAuth 2.0 is mainly about delegated authorization. OpenID Connect adds a standard identity layer on top of OAuth 2.0.

Quick answer

Use OAuth 2.0 when an application needs permission to access protected resources. Use OpenID Connect when an application needs to know who the signed-in user is.

OAuth answers: can this client access this API with these permissions?

OpenID Connect answers: who authenticated, and what identity information can the client rely on?

In practice, many “sign in with Google” or “sign in with GitHub” flows use OpenID Connect-like identity behavior, OAuth 2.0 authorization flows, or provider-specific combinations.

What OAuth 2.0 does

OAuth 2.0 lets a client obtain an access token for protected resources.

For example, a reporting app may ask permission to read a user’s calendar events. The user approves the request, and the authorization server issues an access token. The reporting app can then call the calendar API with that token.

The key idea is delegated access. The client does not need the user’s password. It receives a limited credential for a specific resource server and scope.

Common OAuth concepts include:

  • Resource owner.
  • Client.
  • Authorization server.
  • Resource server.
  • Access token.
  • Refresh token.
  • Scope.
  • Redirect URI.
  • Authorization code.
  • PKCE.

Read OAuth 2.0 Explained for Backend Developers for a deeper walk through the core flow.

What OpenID Connect adds

OpenID Connect, often shortened to OIDC, adds identity concepts on top of OAuth 2.0.

The most important addition is the ID token. An ID token tells the client about the authenticated user and the authentication event.

An ID token often contains claims such as:

{
  "iss": "https://issuer.example.com",
  "sub": "user_123",
  "aud": "client_abc",
  "exp": 1790640000,
  "iat": 1790636400
}

The client can use that information to establish a login session, after verifying the token according to the provider’s rules.

OIDC also standardizes scopes such as openid, profile, and email, plus user info behavior.

Access token vs ID token

The easiest way to avoid confusion is to separate token purpose.

TokenIntended audienceMain purpose
Access tokenAPI or resource serverAuthorize access to protected resources.
ID tokenClient applicationProve authentication and describe the user identity.

An access token is for APIs. An ID token is for the client.

A common mistake is sending an ID token to an API and treating it as an API credential. Another common mistake is treating an access token as proof of user identity without checking whether the architecture supports that.

The openid scope

OIDC flows usually include the openid scope:

scope=openid profile email

That tells the authorization server the client is requesting OpenID Connect behavior, not only OAuth access.

Without openid, a provider may issue an OAuth access token but no ID token. With openid, the client can receive identity information according to the OIDC rules and provider configuration.

Backend login flow

For a backend web app, a simplified OIDC login flow looks like this:

  1. Redirect the user to the identity provider.
  2. Include response_type=code, client ID, redirect URI, scopes, state, and PKCE values.
  3. Receive an authorization code on the callback route.
  4. Exchange the code for tokens from the backend.
  5. Validate the ID token.
  6. Create an application session for the user.

After that, your application usually relies on its own session or token lifecycle.

This is why OIDC is often part of login, but your app still needs its own authorization model.

Authorization still belongs to your app

OIDC can tell you who signed in. It does not automatically answer every permission question inside your product.

For example, an ID token may identify user_123, but your backend must still decide:

  • Can this user view this workspace?
  • Can this user export billing data?
  • Can this user invite teammates?
  • Can this user delete this resource?

That is application authorization. Read Authorization vs Authentication for the distinction.

Common mistakes

The first mistake is saying “OAuth login” without knowing whether OpenID Connect is involved. OAuth alone is not a complete identity protocol.

The second mistake is accepting tokens without validating issuer, audience, expiration, and signature.

The third mistake is using an access token as if it were an ID token. Access tokens are meant for resource servers.

The fourth mistake is putting provider identity directly into application permissions without a local account or tenant model.

The fifth mistake is logging tokens, authorization codes, or identity claims that should remain private.

Practical backend recommendation

Use precise language in your design docs:

  • OAuth 2.0 for delegated API access.
  • OpenID Connect for standardized login and identity.
  • Access tokens for APIs.
  • ID tokens for client authentication context.
  • Application authorization for product permissions.

Then test the unhappy paths: expired tokens, wrong audience, wrong issuer, missing scopes, disabled accounts, and users who are authenticated but not authorized.

Read OAuth 2.0 Explained for Backend Developers for the flow details, API Key vs OAuth Token for credential tradeoffs, and Access Token vs Refresh Token for lifecycle decisions. Use the JWT Decoder to inspect test ID token claims locally. For the full sequence, browse the Authentication Learning Path.

For the broader security sequence, browse the Backend Security Learning Path.

Keep reading