If you've ever clicked a “Log in with Google” button, you've touched protocols like OAuth 2.0 and OpenID Connect (OIDC). But here's the thing: OAuth was never meant for logging in. It was designed for something entirely different — and that's where OIDC comes in.
In this post, we'll cut through the jargon and explain, in plain language, what OAuth is, why people misuse it, and how OIDC fixes the gap.
OAuth: Delegated Authorization
At its core, OAuth (Open Authorization) is a framework for delegated access. The idea is simple:
“I want this app to access some of my resources, without handing it my password.”
Think of it like giving a valet your car keys. You don't want them driving to another city — just parking your car. OAuth defines the rules and limits of that delegation.
A Real OAuth Example: GitHub + CI/CD Tool
Say you're using a CI/CD service (like Netlify, Vercel, or CircleCI). You want it to deploy code from your private GitHub repos. Instead of giving the service your GitHub credentials, you go through an OAuth flow:
- The CI/CD tool redirects you to GitHub's OAuth page.
- GitHub asks: “This app wants to read and write your repos, and manage webhooks. Do you approve?”
- You consent.
- The tool gets an access token from GitHub.
- It uses that token to call GitHub's API on your behalf.
Notice what's missing here: the CI/CD tool doesn't really care who you are. It just needs the ability to act on your repos. That's pure OAuth.
Where Things Got Messy: Using OAuth for Authentication
Over time, developers noticed OAuth's flow worked well for redirecting users, getting tokens, and establishing trust. So they started using it for authentication (logging users in).
But here's the problem: an access token only says, “This token holder can access these resources.” It doesn't prove who the user is.
That gap opened the door for security issues like:
- Token substitution attacks (a stolen token could log someone else in).
- Ambiguity (apps had to invent their own way to figure out user identity).
Clearly, something was missing.
Enter OpenID Connect: Authentication Layer on Top of OAuth
To solve this, the industry created OpenID Connect (OIDC). It's not a separate protocol from OAuth 2.0 — it's a layer on top of it.
OIDC keeps OAuth's machinery (authorization codes, tokens, redirects) but adds identity-specific features:
- ID Token → a special JWT (JSON Web Token) that contains user identity claims (e.g., email, user ID).
- UserInfo endpoint → a standard way to fetch profile information.
- Defined authentication flows → making it safe and interoperable.
Example: “Log in with Google”
When you click Log in with Google:
-
You're redirected to Google's OAuth/OIDC endpoint.
-
You log in (if you aren't already).
-
You approve the app's request.
-
The app gets two tokens:
- An access token (for Google APIs, if needed).
- An ID token (JWT) that says “This is Alice, email alice@gmail.com, verified by Google.”
Now the app can log you in securely, without guessing who you are.
OAuth vs OIDC
- OAuth is a protocol for authorization, letting apps access resources on behalf of users with an access token.
- OpenID Connect is a layer on top of OAuth for authentication, providing ID tokens that securely tell apps who the user is.
OAuth 2.0 Flow (Authorization, e.g. GitHub → CI/CD Tool)
OIDC Flow (Authentication, e.g. Log in with Google)
Takeaways
- OAuth was never meant for authentication. Its purpose is authorization.
- OIDC builds on OAuth to provide authentication via ID tokens.
- If your app needs to access APIs on behalf of a user → use OAuth.
- If your app needs to log in users securely → use OIDC.
- If you try to use OAuth alone for authentication, you're in risky territory.
Closing Thought
Next time someone asks, “Is OAuth an authentication protocol?”, you'll know the answer: No — that's OpenID Connect.
OAuth lets apps act on your behalf. OIDC lets apps know who you are. Together, they power the login buttons and integrations we all use daily.