Identity Protocols: OAuth 2.0 vs. OpenID Connect (OIDC)
Clarifying the critical difference between OAuth 2.0 (Authorization) and OpenID Connect (Authentication) in modern web security.
Overview
In modern application security, developers often confuse OAuth 2.0 and OpenID Connect (OIDC). While they are closely related—and frequently used together—they serve two fundamentally different purposes: Delegation of Access (Authorization) vs. Identity Verification (Authentication).
The Problem
OAuth 2.0 was designed strictly to solve the "Delegated Access" problem. For example, allowing a printing website to access your Google Drive photos without giving the printing site your Google password. It issues an Access Token.
The problem began when developers tried to use OAuth 2.0 to log users in (Authentication). An Access Token only proves that someone granted permission to access an API; it contains absolutely no information about who the user is, how they logged in, or when they authenticated. Using plain OAuth 2.0 for login is a critical security anti-pattern.
Solution and Configuration
OpenID Connect (OIDC) was created to solve this flaw. OIDC is an identity layer built on top of the OAuth 2.0 protocol.
When an application requests login via OIDC, it adds the openid scope to the OAuth authorization request:
GET https://accounts.google.com/o/oauth2/v2/auth?scope=openid email profile&client_id=...
Instead of receiving just an Access Token, the application now receives an ID Token alongside it.
Technical Details
The ID Token is a heavily structured JSON Web Token (JWT). It contains specific, cryptographically signed claims about the user.
Key OIDC Claims include:
- iss (Issuer): Who issued the token (e.g., Google or Entra ID).
- sub (Subject): The unique ID of the user.
- aud (Audience): The specific application this token was generated for.
- exp (Expiration): When the token expires.
Because the ID token is signed (usually using RS256), the client application can verify its cryptographic signature to definitively prove the user's identity without making additional network requests to the provider.
Conclusion
A simple rule of thumb for developers: If your application needs to consume an API on behalf of a user, use OAuth 2.0 (Access Token). If your application needs to know the identity of the person sitting at the keyboard (Login/SSO), you must use OpenID Connect (ID Token).