What is the MCP authorization framework, and why is it based on OAuth 2.1?
Quick Answer
For servers using the Streamable HTTP transport, MCP defines an authorization framework built on OAuth 2.1 (the consolidated, tightened successor to OAuth 2.0 that mandates PKCE and drops legacy insecure grant types): the MCP server acts as an OAuth resource server, an authorization server (which may be the same service or a separate one it delegates to) issues access tokens, and the MCP client acts as an OAuth client, discovering the authorization server via metadata, registering dynamically if needed, and obtaining tokens through a standard authorization code flow with PKCE before it can call the server's protected endpoints. OAuth 2.1 was chosen because it's a mature, widely implemented, well-audited standard for exactly this problem — delegated, scoped, revocable access — rather than MCP inventing a bespoke auth scheme that would need its own security review and tooling ecosystem from scratch. Local stdio servers, by contrast, don't need this at all, since the OS process boundary already provides the trust boundary.
Detailed Answer
Once a server runs remotely and serves multiple users, "just trust the connection" is no longer an option. That's fine for a local stdio subprocess, but a remote server needs real, standard authentication and authorization.
The roles, mapped to OAuth terms
| OAuth role | MCP equivalent |
|---|---|
| Resource server | The MCP server itself (protects tools/resources behind access tokens) |
| Authorization server | Issues tokens; may be run by the same team, or delegated to an existing identity provider |
| Client | The MCP client, acting on behalf of the user |
| Resource owner | The user |
A simplified flow
1. Client attempts to connect to the MCP server, gets a 401
2. Client discovers the authorization server via metadata
(well-known endpoints describing where to authenticate)
3. Client performs OAuth 2.1 authorization code flow + PKCE,
redirecting the user to log in and consent
4. Client receives an access token
5. Client includes the token on every subsequent MCP request:
Authorization: Bearer <token>
6. Server validates the token before processing tools/resources requests
Why OAuth 2.1 specifically, not a custom scheme
- It's a mature, heavily scrutinized standard with existing libraries, identity providers, and security research behind it. Rolling a bespoke token scheme would mean re-discovering, often the hard way, security pitfalls OAuth already learned from.
- OAuth 2.1 specifically mandates PKCE and removes legacy flows, like the implicit grant, that had known weaknesses. That gives MCP a stronger baseline than plain OAuth 2.0 would.
- It supports delegation cleanly. An MCP server doesn't have to build its own user-management/login system — it can lean on an existing identity provider as its authorization server.
What this means for local vs. remote servers
None of this applies to a local stdio server. The trust boundary there is simply "whatever process the OS lets run as this user" — a different, and generally weaker but locally-scoped, security model entirely. OAuth-based authorization is specifically the answer for the remote/shared-service case, where a server has no other way to know who's calling it.