If you’ve ever clicked “Sign in with Google” or “Connect with Facebook” on a website or app, you’ve interacted with technologies called OAuth and OpenID Connect (OIDC). These two standards form the backbone of secure authentication and authorization on the web today.
This guide will walk you through everything you need to know, in simple language and step-by-step explanations. By the end, you’ll have a solid grasp of both protocols, their roles, and why they matter.
Authentication and Authorization
Before diving into OAuth and OIDC, it’s important to understand two key concepts:
- Authentication → process of verifying who you are. For example, logging in with your username and password proves your identity.
- Authorization → process of determining what you’re allowed to do. For instance, once logged in, determining if you have permission to access certain files or perform specific actions.
The Limitations of Password-Based Logins (and Why OAuth/OIDC Exist)
Most websites and apps still rely on the traditional method of logging in with a username and password. While simple, this approach has several serious drawbacks:
User Experience Challenges
- Remembering multiple passwords is difficult.
- Users face friction creating and managing separate accounts.
Security Threats
- Phishing attacks trick users into handing over passwords.
- Weak or reused passwords put accounts at risk.
Storage and Management Burdens
- Storing passwords securely is challenging.
Single Sign-On and Federated Login to the Rescue
As we’ve seen, managing multiple usernames and passwords is both inconvenient and insecure. Single Sign-On (SSO) reduces password fatigue by letting you log in once to access multiple apps within the same organization.
However, SSO typically works only inside one organization or domain. Federated Login solves this by letting you use trusted providers like Google or Facebook to sign in across different websites. This builds cross-domain trust without needing separate passwords for every service.
OAuth 2.0 provides the framework for handling secure access to user data without sharing passwords. OpenID Connect (OIDC) builds on OAuth to add login and identity, making federated login possible across websites.
OAuth 2.0 Intuition
Think of OAuth like getting a signed access pass from City Hall so you can pick up someone else’s property from a secure warehouse.
Here’s how it works:
- Your friend (Resource Owner) wants You (Client) to pick up their box from the Warehouse (Resource Server).
- Your friend goes to City Hall (Authorization Server). At City Hall:
- They present their ID for identity verification (e.g., username/password).
- They explicitly state → “I want to authorize this person to collect my box”.
- City Hall reviews and approves the request. They issue your friend an Authorization Letter.
- Your friend gives You the authorization letter from City Hall, saying → “Take this back to City Hall to get your official access pass”.
- You take the authorization letter back to City Hall :
- City Hall verifies the authorization letter by confirming that it’s legitimate and hasn’t expired.
- City Hall then issues you a signed access pass.
- You take the signed access pass to the Warehouse (Resource Server):
- The Warehouse examines the pass, verifies City Hall’s signature to ensure it’s authentic.
- It checks who authorized it (your friend), whom it’s allowed for (you), what it allows (picking up the box), and expiry date.
- Once all details are validated, the Warehouse gives you the box on behalf of your friend.
OAuth 2.0: The Authorization Framework
When a client app needs to act on a user’s behalf → like accessing their files, calendar, or other resources → it needs a way to request permission securely. OAuth 2.0 provides a standardized framework for this authorization, allowing users to grant limited access to the apps without sharing their passwords with them.
OAuth 2.0 focuses purely on what an app is allowed to do, not who the user is. That’s where OpenID Connect (OIDC) comes in, adding authentication on top of OAuth 2.0 to verify user identity.
Because OIDC is built on OAuth 2.0, understanding OAuth first makes everything else clearer. That’s why we’ll begin by exploring OAuth 2.0 in detail.
OAuth 2.0 Flow Types For Different Use Cases
OAuth 2.0 defines different flows to handle different scenarios securely. In each scenario, the actors and their capabilities can vary, which is why there are different flows tailored to specific use cases.
In this article, we’ll focus on the Authorization Code flow (non-PKCE) because it demonstrates the core OAuth concepts most clearly.
Authorization Code Flow
The Four Key Players
- Resource Owner (Your Friend): The user who owns the protected resources.
- Client (You): The application requesting access on the resource owner’s behalf.
- Authorization Server (City Hall): Authenticates the resource owner, client and issues signed access tokens.
- Resource Server (Warehouse): Hosts the protected resources and verifies access tokens before granting access.
Client Registration And End-To-End Flow
Before the OAuth flow can even start, the Client app must be registered with the Authorization Server (like Google, Microsoft, etc.). Think of this as the client obtaining an official ID that proves who it is whenever it requests authorization.
During registration, the Authorization Server issues:
- Client ID: A public identifier for your app (like a username for the app).
- Client Secret: A private key for server-side authentication (like a password for the app that must be kept secret).
- Redirect URI: The specific URL on the client app where the Authorization Server will send the user after authorization (like telling the Authorization Server, “After login, send them back here”).
As explained in the example above, the Authorization Code flow has two key phases:
Phase 1: Resource Owner Authentication & Consent
The resource owner authenticates with the authorization server and grants permission to the client app.
Phase 2: Client Authentication & Token Exchange
The client app authenticates itself and exchanges the authorization code for the access token.
The authorization code issued by the Authorization Server simply represents the authorization granted by the resource owner to the client app.
But there’s a key problem: The authorization code doesn’t tell the client who the resource owner actually is.
In other words, OAuth alone doesn’t help the client app verify that the person using it is really the resource owner who granted the permission.
Why does this matter? → Because the client is acting on behalf of the user and it needs to be sure that the person interacting with it is indeed the same resource owner who gave that authorization. Otherwise, the client might present or act on sensitive user data for the wrong person. This is the gap that OpenID Connect (OIDC) solves.
OpenID Connect (OIDC): Adding Identity to OAuth
OIDC is a simple identity layer built on top of OAuth 2.0. It extends the OAuth flow by returning an ID Token alongside the Access Token. This ID Token contains information about the authenticated user. In other words:
- OAuth 2.0 → Authorization (what can the app do?)
- OpenID Connect → Authentication + Authorization (who is the caller user, and what can the app do on their behalf?)
In the next article(s), we’ll dive into how access tokens are actually implemented in real-world systems.
If you have any feedback on the content, suggestions for improving the organization, or topics you’d like to see covered next, feel free to share → I’d love to hear your thoughts!
Top comments (0)