Why OAuth Exists
The scenario everyone recognizes
Your application wants to access a user's data on another service — their Google Calendar, GitHub repositories, or company files in SharePoint.
The naive approach: ask for their password.
YourApp: "Enter your Google password so we can read your calendar."
User: "...no."
That fails for obvious reasons:
- Trust — the user must fully trust your app with their primary credentials.
- Scope — you get all access, not just calendar read.
- Revocation — changing the Google password breaks your app and every other service.
- Audit — Google cannot tell "the user logged in" from "YourApp logged in on their behalf."
OAuth exists to fix this. Its core idea is delegated authorization: the user grants your application limited permission without handing over their password.
What OAuth is (one sentence)
OAuth lets a user authorize a third-party application to access their resources on a resource server, without sharing their credentials with that application.
Notice what is not in that sentence: "login," "identity," or "authentication."
OAuth is primarily an authorization framework. In practice we use it for login because "who approved this access?" implies "who is this person?" — but that identity layer (OpenID Connect) is a separate spec built on top of OAuth 2.0.
A durable analogy: the valet key
When you valet park, you do not hand over your house keys. You hand over a valet key that:
- starts the car
- does not open the glove box or trunk (unless the manufacturer allows it)
- can be collected when you leave
OAuth access tokens work the same way:
| Real world | OAuth |
|---|---|
| You (car owner) | Resource owner (user) |
| Valet company | Client application |
| Car manufacturer key system | Authorization server |
| Your car | Resource server (API) |
| Valet key | Access token |
The valet never learns your main key. Your app never learns the user's Google password.
The problem OAuth does not solve
OAuth is not a silver bullet. It does not:
- Replace your application's authorization (what roles can do inside your app)
- Eliminate the need for secure coding (XSS, CSRF, SSRF still matter)
- Choose your user directory (LDAP, database, social login — you still decide)
- Ship a finished login UI (you build or embed consent screens)
- Handle compliance by itself (GDPR, SOC2, retention — still your process)
Buying Keycloak, Okta, or Auth0 gives you a strong authorization server — not a finished product.
A brief history (why there are so many terms)
| Era | What happened |
|---|---|
| OAuth 1.0a | HMAC signatures, painful for mobile/SPA |
| OAuth 2.0 (2012) | Simpler bearer tokens; multiple "grant types" |
| OAuth 2.1 (draft) | Community cleanup: PKCE everywhere, deprecate risky grants |
| OpenID Connect (OIDC) | Standardized identity layer on OAuth 2.0 |
You do not need OAuth 1.0a for new work. This series focuses on OAuth 2.0 + OIDC, with Authorization Code + PKCE as the only flow you should implement for user-facing apps.
When to reach for OAuth
| Situation | OAuth? |
|---|---|
| User signs in via Google/GitHub/company SSO | Yes |
| Your SPA calls an API on behalf of a logged-in user | Yes |
| Server-to-server batch job with no user | Different pattern (client credentials) |
| Two microservices inside your VPC | Often mutual TLS or internal IAM, not user OAuth |
| "Remember me" inside your own monolith | Session cookies may be enough |
Go deeper
Resource owner vs client vs authorization server
Even in "Login with Google," three parties exist:
- Google (authorization + resource server for Google APIs)
- Your app (client)
- The user (resource owner)
Your app receives a token about the user, not from the user directly.
Why "OAuth for login" took over
Before OIDC, every provider returned different user profile JSON. OIDC standardizes:
- an
id_token(JWT with identity claims) - a
/userinfoendpoint - discovery via
/.well-known/openid-configuration
So "OAuth login" in 2026 really means OIDC on top of OAuth 2.0.
OAuth vs API keys
API keys identify the application, not a user on behalf of whom the app acts. OAuth adds user consent and scoped, revocable delegation.
What you should know after this post
- You can explain delegated authorization without saying "it's login"
- You know why sharing passwords is the anti-pattern
- You recognize OAuth solves access to resources, not your entire security model