What’s the difference between authentication and authorization, and how does OAuth 2.0 fit in?
Authentication answers “who are you,” verifying identity, typically via a password, a certificate, or a passkey. Authorization answers “what are you allowed to do,” deciding whether an already-authenticated identity can perform a specific action on a specific resource. They’re sequential and distinct: you authenticate once, then every subsequent action gets checked against authorization rules.
Where OAuth 2.0 actually fits
OAuth 2.0 is an authorization framework, not an authentication protocol, despite being used in login flows constantly. It solves a specific problem: letting a user grant a third-party application limited access to their resources on another service, without handing over their password. When you click “Sign in with Google” and get asked “allow this app to access your email,” that’s OAuth granting delegated, scoped access, not proving identity to the third-party app directly.
Best practice
If you actually need to authenticate a user’s identity (not just get delegated access to a resource), use OpenID Connect, which is built as an identity layer on top of OAuth 2.0 specifically to close this gap, adding an ID token that carries verified identity claims. Using bare OAuth 2.0 alone to “log a user in” is a well-known anti-pattern since OAuth access tokens were never designed to prove identity to the client application.
Edge case interviewers probe for
Ask what happens if an access token is stolen. Since OAuth access tokens are typically bearer tokens, whoever holds the token can use it, there’s no separate proof of identity attached. This is why short token lifetimes, refresh token rotation, and scoping tokens to the minimum necessary access all matter, limiting the blast radius of a stolen token.
Common mistake
Treating “the user completed an OAuth flow” as equivalent to “the user is authenticated” without verifying an ID token (OpenID Connect) or otherwise confirming identity, conflating delegated resource access with proof of who someone is.
What the interviewer is checking
Whether you understand OAuth’s actual purpose (delegated authorization) rather than treating it as a generic “login” black box, and whether you know OpenID Connect is the piece that adds real authentication.
Authentication is showing your ID at the door to prove you are who you say you are. Authorization is the bouncer checking whether your ticket lets you into the VIP section or just the main floor, a separate question from “are you really Alex.”
OAuth is like giving a valet a special key that only starts your car and opens the trunk, not your house key. You’re not proving your identity to the valet, you’re handing over limited, specific access (park my car) without giving them everything (your house key, your identity, your full life). “Sign in with Google” works the same way: the app gets a limited key to specific things (like your email), not your actual Google password, and not automatically proof of who you are, that part needs an extra piece (OpenID Connect) layered on top.
Why interviewers ask this
OAuth is used everywhere but widely misunderstood as a login protocol. This checks whether you know what it actually does versus what it’s commonly (mis)used for.
What a strong answer signals
That you distinguish delegated authorization from identity verification, and know OpenID Connect is the layer that actually authenticates.
Common follow-ups
- What’s the difference between an access token and a refresh token?
- What is the authorization code flow and why is it preferred over implicit flow?
- How would you revoke access if a token is compromised?
Advanced variation
“Design an authorization system with role-based and resource-based permissions,” which expects discussion of RBAC versus ABAC and where OAuth scopes fit relative to your own application’s finer-grained permission model.
A team building a “Sign in with Google” flow initially just checked for a valid OAuth access token and treated its presence as proof of login, without verifying an ID token. This meant any app the user had ever granted even minimal access to could potentially be swapped in to satisfy the check, since the flow never actually verified identity, only that some access had been granted. Switching to OpenID Connect and verifying the signed ID token’s claims (issuer, audience, expiry) closed the gap, correctly separating “this token grants access to X” from “this proves the user is who they claim.”
- 1Authentication verifies identity; authorization decides what an identity can do.
- 2OAuth 2.0 is an authorization framework for delegated access, not an authentication protocol.
- 3OpenID Connect is built on top of OAuth 2.0 specifically to add real identity verification.
- 4OAuth access tokens are typically bearer tokens; a stolen one grants access without proving identity.
- 5Never treat “completed an OAuth flow” as equivalent to “user is authenticated” without an ID token.