Overview
OpenID (and OpenID Connect) and OAuth (OAuth 2.0) are two widely used standards in modern web identity and security. They are related but solve different problems: authentication vs authorization. Understanding their differences, how they work together, and typical use-cases is essential for architects and developers building secure applications.
What is OAuth?
OAuth 2.0 is an authorization framework that enables applications to obtain limited access (via an access_token) to a user’s resources on another service without exposing user credentials. OAuth answers the question: “Can this app access this resource on behalf of the user?” It does not define how to authenticate the user.
What is OpenID / OpenID Connect (OIDC)?
OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0. OIDC allows clients to verify the identity of the end-user using an id_token (usually a signed JWT) and to obtain basic profile information (scopes like openid, profile, email). OIDC answers the question: “Who is the user?”
Core Differences
Primary Purpose
OAuth 2.0: Authorization (granting apps scoped access to resources).
OpenID Connect: Authentication (proving the user’s identity).
Tokens
OAuth 2.0 issues access_token (and optionally a refresh_token) for resource access. These tokens are typically opaque to clients or contain scopes and expiry.
OIDC introduces the id_token (a JWT) containing user identity claims (sub, email, name, etc.) used to authenticate the user.
Standardized Claims & Endpoints
OIDC standardizes user claims (like sub, email, preferred_username) and discovery endpoints (e.g., /.well-known/openid-configuration) which makes integration simpler and interoperable.
Flows
OAuth flows (authorization code, client credentials, implicit, device code) focus on obtaining access tokens for APIs. OIDC typically uses the OAuth authorization code flow (or hybrid/implicit for legacy clients) and returns an id_token together with the access_token for authentication + authorization scenarios.
Typical Use-Cases
OAuth-only
API-to-API communication where no user is involved (use client credentials). Also used when granting limited API access without needing to authenticate the user (e.g., a third-party app accessing a user’s calendar data).
OIDC (OpenID Connect)
Web and mobile applications that need to sign users in, build user sessions, and retrieve profile information. OIDC is preferred when you need a standard, interoperable authentication mechanism.
Example: Authorization Code Flow (OIDC-enabled)
Typical endpoints involved:
GET /authorize?response_type=code&client_id=...&redirect_uri=...&scope=openid%20profile%20email
After exchange:
POST /token -> returns { access_token, id_token, refresh_token }
The id_token is a signed JWT the client validates (issuer, audience, signature, expiry) to authenticate the user.
Security Considerations
– Do not use OAuth implicit flow for SPAs; prefer authorization code flow with PKCE.
– Validate id_token claims (iss, aud, exp, nonce) when using OIDC.
– Use HTTPS, short token lifetimes, and rotate client secrets.
– Distinguish scopes: openid scope triggers OIDC behavior.
How they work together
OIDC reuses OAuth 2.0 mechanisms for delegation and adds identity semantics. In practice, most identity providers implement both: OAuth for API authorization and OIDC for user authentication, allowing a single flow to authenticate the user and get an access token to call APIs.
Quick Comparison Table (summary)
– Purpose: OAuth = Authorization; OIDC = Authentication + Identity
– Tokens: OAuth = access/refresh tokens; OIDC adds id_token (JWT)
– Use-case: OAuth for API access; OIDC for sign-in and SSO
– Built-on: OIDC is built on top of OAuth 2.0
Conclusion
In short: use OAuth 2.0 when you need to grant applications access to resources, and use OpenID Connect when you need to authenticate users and obtain identity information. Combining both gives you authenticated users and authorized API access in a secure, standardized way.