Comparison
API
OAuth
Authentication
Developer Reference

OAuth 2.0 vs OpenID Connect

Authorization vs authentication — understanding why "Login with Google" needs both and what each token actually does.

Part of the API Authentication Methods guide series.

The short answer

OAuth 2.0 is an authorization framework — it lets a user grant an application access to their resources without sharing passwords. OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0 — it adds a standardized way to verify who the user is. For any "Sign in with" flow, you need OIDC. For pure API access delegation, OAuth 2.0 alone is sufficient.

Quick Decision

Use OAuth 2.0 alone when…

You are granting a service access to resources on behalf of a user (e.g. a GitHub app reading repos).

You are building machine-to-machine (M2M) API access with client credentials.

You do not need to know who the user is — only that they granted access.

Use OAuth 2.0 + OIDC when…

You are building a "Sign in with Google / GitHub / Apple" flow — you need identity.

You need the user's name, email, or profile information in a standardized format.

You want SSO across multiple applications from one identity provider.

The Critical Distinction

The single most important thing to understand: OAuth 2.0 was never designed for authentication. It was designed to answer the question "does this user permit this app to do X?" — not "who is this user?"

OAuth 2.0 — Authorization

Answers: Can this app access that resource?

  • Issues an access token (usually a JWT or opaque token)
  • Access token carries scopes (permissions), not user identity
  • Resource servers validate access tokens to decide what the app can do
  • No standard for "who is the user" — apps interpret tokens differently

OIDC — Authentication

Answers: Who is this user?

  • Issues an ID token (always a JWT) alongside the access token
  • ID token carries standardized identity claims: sub, name, email, picture
  • Client application reads the ID token to identify the user
  • Standardized — any OIDC client can consume any OIDC provider

OIDC does not replace OAuth 2.0 — it extends it. An OIDC flow runs the full OAuth 2.0 authorization code flow, then returns both tokens: the access token (for calling APIs) and the ID token (for the client to learn who logged in).

Side-by-Side Comparison

DimensionOAuth 2.0OIDC (on top of OAuth 2.0)
Primary purposeAuthorization — delegated resource accessAuthentication — verify user identity
Token issuedAccess token (+ optional refresh token)ID token + access token + optional refresh token
Token formatOpaque or JWT (provider-defined)ID token is always a JWT; access token format varies
Who consumes the tokenResource server (API)ID token → client app; access token → resource server
Standard identity claimsNone — scope is about permissions, not identitysub, name, email, picture, locale, nonce, etc.
User info endpointNot standard/userinfo endpoint returns claims for the access token
Typical use caseApp reads user's GitHub repos; M2M service token"Sign in with Google"; SSO; federated identity

What OIDC Adds to OAuth 2.0

An OIDC authorization request looks almost identical to an OAuth 2.0 request — the difference is the openid scope. Adding it signals that the authorization server should return an ID token alongside the access token.

1

The ID Token

A JWT signed by the identity provider. Contains: sub (stable user identifier), iss (issuer), aud (your client ID), iat/exp (timestamps), and optional claims like name, email, and picture. The client verifies the signature and reads claims — no additional network request required.

2

The UserInfo Endpoint

A protected endpoint (typically /userinfo) that returns additional claims when called with the access token. Useful when the ID token is kept small and you need profile data on demand. The response is also a signed JWT in some implementations.

3

Standard Scopes

OIDC defines standard scopes: openid (required), profile (name, picture, locale), email (email, email_verified), address, and phone. Providers map these to ID token claims consistently — unlike OAuth 2.0 where scope semantics are provider-defined.

Which Grant Types Apply

Grant TypeOAuth 2.0OIDCNotes
Authorization Code✅✅Standard flow for web and native apps. Always prefer this.
Auth Code + PKCE✅✅Required for SPAs and mobile apps. Replaces implicit flow.
Client Credentials✅❌Machine-to-machine only. No user, so no ID token possible.
Implicit (deprecated)⚠️⚠️Tokens in URL fragment — avoid. Use Auth Code + PKCE instead.
Device Code✅✅TVs, CLIs, and devices without a browser. User authenticates on another device.

Common Mistakes

Using OAuth without OIDC for login
If you implement "Login with Google" using OAuth 2.0 but without the openid scope, you get an access token with no standardized identity. You cannot reliably identify the user from an OAuth access token alone — different providers format user data differently. Always add openid (and usually profile email) when you need identity.
Using ID tokens as API access tokens
ID tokens are for the client application — they prove who logged in. They are not intended to be sent to resource servers as bearer credentials. Your APIs should validate access tokens (which carry scopes). Sending ID tokens to APIs may expose user PII unnecessarily and bypasses proper scope enforcement.
Skipping nonce validation
The nonce is a random value your app includes in the authorization request and that the ID token must echo back. Skipping nonce validation opens you to replay attacks where a stolen ID token from one session is replayed in another. Always generate and verify nonces for OIDC flows in browser-based apps.
Using the implicit flow
The implicit flow returns tokens directly in the URL fragment (e.g. #access_token=...). This exposes tokens to browser history, referrer headers, and logs. The OAuth 2.0 Security BCP (RFC 9700) recommends against implicit flow for all new implementations. Use authorization code with PKCE instead.

Inspect your OAuth or OIDC tokens

Paste an access token or ID token to decode its claims, check scopes, inspect the issuer, and verify expiry — all in your browser.

OAuth Token ValidatorJWT Token Validator

Frequently Asked Questions

Related Resources

Back to Comparisons