A friendly walk-through of what OAuth is, what it solves, and the words you'll meet in Part 1 (the protocol) and Part 2 (MCP servers and the provider landscape).
Imagine you drive to a hotel. You hand the valet a special key that only opens the doors and starts the engine — it doesn't open the boot, the glove box, or your house. You can take it back at any time. That is OAuth.
That button uses OpenID Connect — a small identity layer built on top of OAuth. It bundles "who you are" with "what you may do" into one round trip. We'll see it later.
"AuthN is the bouncer at the door. AuthZ is the wristband that says which rooms you can enter."
Roll back to ~2006. You upload photos to Flickr. A new printing site, "PhotoPrint", offers to turn them into a calendar — "just give us your Flickr password". People did. It was a disaster.
"App A wants to do thing R on user U's behalf at service S — without ever seeing U's password." Every part of OAuth exists to make that one sentence safe.
You've done it a hundred times. Click the button on a website, end up on Google, click "Allow", land back on the site already logged in. Behind the scenes:
Step 5 — the consent screen — is the moment of delegation. Without it, OAuth would just be password-sharing with extra steps.
The app sends you to the auth server with a request: "I'm app X, I want these permissions, send me back here when done."
The auth server makes you log in (if you aren't already). Password, passkey, MFA — whatever the org's policy says. The app never sees this.
The auth server shows you what the app is asking for in plain language. You click Allow (or Deny).
The auth server hands the app a short-lived access token — the valet key. (And usually a longer-lived refresh token to mint new access tokens later.)
The app calls the resource's API, attaching the token. The resource verifies the token and serves the request.
Same five beats. The differences between flows are where each step happens — in a browser, on a server, on a TV — and how the token gets back to the app.
A token is just a string of characters that means "the bearer of this is allowed to do X for the next Y minutes". It's a digital wristband.
Most tokens are bearer tokens — like cash. Whoever holds it can spend it. Modern OAuth has stronger options (DPoP, mTLS) that bind the token to the legitimate holder, but the default mental model is "treat it like cash".
Never log a token. Never put one in a URL. Never email one. Treat them like passwords.
A scope is just a label that says "this token may do this specific thing". The auth server stamps the scopes onto the token; the resource server checks them on every call.
email · profile — your name and emailread photos · upload photosread your repositories · create issuessend messages on your behalfsee your calendar · add events to your calendarGranular scopes let you say "yes to read my photos, no to delete them". They also let the app be honest about what it actually needs — and let users walk away if it's asking for too much.
Scope says what the token can do; audience says which service it can do it to. A token issued for "Slack" shouldn't be usable at "GitHub", even if both trust the same auth server. Audience is how OAuth keeps tokens from being laundered between APIs.
| Word | Plain meaning | The valet analogy |
|---|---|---|
| Resource Owner | The user (you). | The car owner. |
| Client | The third-party app asking for access. | The valet. |
| Authorization Server (AS) | The trusted service that authenticates you and issues tokens. | The hotel front desk that prints valet keys. |
| Resource Server (RS) | The API or service holding your data. | The car. |
| Scope | A specific permission attached to a token. | "May start engine; may not open boot." |
| Audience | Which service the token is meant for. | "Key works at this hotel only." |
| Access token | The credential the client sends to the resource server. | The valet key. |
| Refresh token | A longer-lived credential used only to mint new access tokens. | The card you exchange at the desk for a fresh key. |
| ID token | A signed statement saying "this is user U" (OpenID Connect). | The receipt with your name on it. |
| Consent screen | The "App X wants to: …" dialog the AS shows you. | "Sir, the valet would like to start your engine — OK?" |
| Grant / Flow | A specific recipe for getting a token (different recipes for browser, mobile, TV, server-to-server). | Different ways to hand over the key (in person, posted, on-screen code). |
| PKCE | An extra secret only the legitimate app knows, sent at the end to prove it's the same app that started the flow. Pronounced "pixie". | A wristband stamp the valet must show to claim the key. |
| OpenID Connect (OIDC) | A small identity layer on top of OAuth — adds the ID token. | OAuth + the receipt with your name on it. |
| Bearer token | A token where "whoever holds it can use it" — like cash. | A valet key anyone could pick up and use. |
| DPoP / mTLS | Ways to bind a token to the legitimate holder, so a stolen one is useless. | A key that only works if you also present your fingerprint. |
An access token says "this app may call this API", not "this is Alice". If you build a "log in" feature using just an OAuth access token, you've built a bug — the user has no proven identity inside your system. OpenID Connect is what adds identity (an ID token) on top.
OAuth doesn't encrypt your data or your tokens — TLS does. OAuth assumes the channel is already secure. Run everything over HTTPS, end of story. Tokens travel in clear over an encrypted pipe.
OAuth is a framework with several flows (browser, mobile, TV, server-to-server) and many optional extensions. There is no single "OAuth library" you bolt on; pick the right flow for your situation. Part 1 walks you through that choice.
OAuth is the plumbing for delegation: handing an app a limited, expiring, revocable, audit-able permission to act on your behalf. Anything beyond that — login, encryption, governance, MFA, single sign-on — is a different problem that often uses OAuth as one ingredient.
OAuth runs more of your day than you realise.
gh auth login, gcloud auth login, az login — open a browser, you click Allow, the CLI gets a token.The Model Context Protocol (Anthropic, 2024) is an open standard that lets LLM apps — Claude Desktop, Cursor, claude.ai, Goose, custom agents — call tools and read resources in a uniform way. Think "USB-C for AI integrations".
Remote MCP didn't invent any new authorisation idea — it picks the modern OAuth defaults and pins them. If you understand OAuth, you understand MCP auth.
You give "PhotoPrint" your Flickr password. Why is that not what OAuth does?
Because OAuth never shares the password. The app is sent to Flickr's auth server, you log in there, you click Allow, and the app gets a token instead. The password stays with you and Flickr.
An access token says "this client can call this API". Can you use it as proof of who the user is in your app?
No. An access token is permission, not identity. For identity, use the ID token from OpenID Connect. Conflating them is the most common OAuth bug in the wild.
Why are access tokens short-lived (5–60 min) when refresh tokens last for days or months?
Damage limitation. The access token travels widely (every API call) so it's the most likely to leak — keep its lifetime short. The refresh token only ever talks to the auth server, over a strictly-controlled channel, so it can be longer-lived. Together you get convenience (no constant re-login) and a small breach window.
You have the right mental model. Part 1 will turn it into the actual protocol; Part 2 will apply it to MCP servers and the provider landscape.
Aimed at: anyone new to delegated auth, including non-developers.
Aimed at: developers building or integrating an OAuth client / server.
Aimed at: anyone shipping or operating remote MCP servers.
Part 0 (this deck, ~15 min) → Part 1 (full protocol, ~45 min) → Part 2 (MCP & providers, ~45 min). If you already write OAuth code, skip straight to Part 2 and use Part 1 as reference.
Ask → Authenticate → Consent → Token → Use. Every flow you'll ever meet — browser, mobile, TV, MCP server — is a variation on those five beats.
Resource owner · client · authorization server · resource server · scope · audience · access token · refresh token · ID token · consent · grant / flow · bearer token · PKCE · OpenID Connect · DPoP / mTLS.
Every one of those will reappear in Part 1 with the full technical treatment.
Part 1 — Introduction to OAuth for the protocol; Part 2 — OAuth for MCP Servers & the Provider Landscape for the AI-agent and provider angle.
OAuth is the polite way to lend your account to someone else's app — for a little while, for a specific purpose, with the right to take it back.