# 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.

```text
YourApp: "Enter your Google password so we can read your calendar."
User:    "...no."
```

That fails for obvious reasons:

1. **Trust** — the user must fully trust your app with their primary credentials.
2. **Scope** — you get *all* access, not just calendar read.
3. **Revocation** — changing the Google password breaks your app *and* every other service.
4. **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 `/userinfo` endpoint
- 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