The Confusion That Trips Everyone Up
OAuth 2.0 and OpenID Connect (OIDC) are used together so frequently that engineers often treat them as the same thing. They are not. Understanding the distinction is essential for designing secure systems and for passing any senior-level security interview.
OAuth 2.0: A Delegation Protocol for Authorization
OAuth 2.0 is a protocol for authorization — specifically, for delegated authorization. It answers the question: "Can application B act on behalf of user Alice to access resource C, without Alice giving application B her password?"
Think of it like a hotel key card. The key card lets you access your room and the gym (authorization). But the key card itself doesn't have your photo or name on it — it doesn't prove who you are to someone just looking at the card. It just grants access to specific resources. The hotel (the authorization server) issued the card after you checked in, but the gym door doesn't need to know your name — it just needs to know the card is valid for that door.
In practice: a data visualization tool (the "client") wants to read your Google Sheets (the "resource"). OAuth 2.0 lets Google issue that tool a time-limited access token scoped only to reading your sheets — without the tool ever seeing your Google password.
Key OAuth 2.0 concepts:
- Resource Owner: The user (Alice) who owns the data.
- Client: The application requesting access (the visualization tool).
- Authorization Server: The entity that issues tokens (Google, Okta, Azure AD).
- Resource Server: The API or service being accessed (Google Sheets API).
- Scope: A string declaring what access is being requested (e.g., sheets.readonly).
OpenID Connect (OIDC): Authentication Built on OAuth 2.0
OIDC is a thin identity layer built on top of OAuth 2.0 that adds authentication. It answers the question: "Who is this user?"
Going back to the hotel analogy: OIDC is the process at the front desk where you show your physical passport to prove your identity before the hotel issues you the key card. The front desk verifies who you are; the key card grants you access.
OIDC allows an application to verify the identity of the user based on authentication performed by a trusted Authorization Server, and to receive standardized profile information about them. It introduces one critical new artifact that OAuth 2.0 lacks: the ID Token.
Interviewers frequently ask: "What's the difference between OAuth 2.0 and OIDC?" A weak answer conflates them. A strong answer is: "OAuth 2.0 is an authorization framework — it grants access to resources but says nothing about who the user is. OIDC is an authentication protocol built on top of OAuth 2.0 that adds an ID Token to tell the application who the user is. You use OAuth 2.0 when you need delegation; you use OIDC when you need to know the user's identity."