OAuth

What is OAuth, and how does it differ from handing a password directly to a third-party application?

OAuth is an authorization protocol that lets a user grant a third-party application (an MCP connector, for instance) permission to access a service's data or functionality on their behalf, without ever handing over their password to that third party. The core of the whole flow is the Token: after the user authenticates through their existing, trusted identity system (logging into their own Google account, for example), that system issues a scope-limited token to the third-party application — a token that can only do the specific things it was authorized for, not the account's full access.

The key difference from handing over a password is scope and revocability. If a password leaks, control of the entire account goes with it; an OAuth token, by contrast, can be limited to reading only specific data, valid only for a specific window of time, and the user can revoke it at any time through the identity system without needing to change their password or compromise the account's overall security.

Why is OAuth needed, and what problem does it solve?

Before mechanisms like OAuth existed, if a third-party application needed to access a user's data on another service, the only option was to ask the user to type their password directly into that third party for storage. This created two concrete risks. First, if that third party was ever breached, what leaked was the user's actual password — an attacker could use it to do anything on the original service, with no scope restriction at all. Second, the user had no fine-grained control — only "authorize everything" or "don't use it at all," with no way to allow read access without also allowing write access, for instance.

OAuth turns authorization from "hand over a password" into "issue a scope-limited Token," solving exactly these two problems: even if a third-party application holding the token gets breached, what leaks is only that token, and whatever an attacker can do with it is confined to the authorized scope; the user or service can also revoke that token at any time without touching the original password. At the same time, users can see exactly which permissions they're granting at the moment of authorization, making a more fine-grained decision instead of an all-or-nothing choice.

How does OAuth actually work, and what does a typical authorization flow look like?

Take Claude connecting to an MCP Server as an example. A typical flow runs roughly like this: Claude first tries calling the server; if it requires authorization, it returns an "unauthorized" response carrying the location of an authorization server. Claude then looks up that authorization server's published metadata to learn what authorization methods it supports. Since Claude doesn't necessarily already know this server's identity in advance, it first registers itself with the server through dynamic client registration, obtaining an identifier. Then comes the actual user authorization step — a browser window opens where the user logs into their own account on that service and confirms which permissions to grant. Once the user confirms, the service issues a credential that Claude exchanges for a formal access Token, and from then on, every call to that server carries this token as proof of authorization.

One common security mechanism in this process is PKCE (Proof Key for Code Exchange), which prevents a credential from being intercepted mid-transit during the authorization process and reused by an attacker. Tokens also typically have an expiration and are periodically rotated, to avoid extending the risk window that comes with a single token being used over a long period.

What does OAuth actually mean for me, and what should I watch for as a user versus as a developer?

If you're a general user and see an authorization screen pop up while connecting Claude to a third-party service (linking Gmail or Slack through a connector, for instance), you're going through an OAuth flow — it's worth actually reading the permission scope listed on that screen and confirming it matches what the connector is actually meant to do, rather than just clicking confirm on reflex. Also remember you can go into that service's account settings at any time to review which third-party applications are currently authorized, and revoke anything you no longer need or that looks suspicious.

If you're building an MCP Server for Claude to use, OAuth is currently the standard requirement in production environments: if your server only supports a static API key, users on claude.ai's web custom-connector interface (which, unlike Claude Code, only accepts OAuth) won't be able to connect it directly. Setting up OAuth authorization involves handling a fair number of details (correctly formatted authorization metadata, implementing PKCE, a Token rotation mechanism), and if you'd rather not build it all from scratch, there are existing middleware options worth considering — but it's still worth understanding exactly what this mechanism protects and whether your server currently meets the standard before adopting one.