How MCP Authorization Converged on OAuth in 18 Months

The Model Context Protocol went from having no protocol-level authorization to a conventional OAuth resource-server architecture in eighteen months. More important than the speed was the direction: each revision removed MCP-specific invention and moved closer to established OAuth standards.

That history shows what healthy protocol design looks like. The first design made the MCP server do too much. The current design separates the resource server, authorization server, client, and enterprise identity provider. The remaining agent-authority gaps now sit above a much stronger base.

Five revisions changed the authorization model

The table compresses several architectural reversals. Those reversals are the story.

The first OAuth model coupled server and issuer

The March 2025 specification added a comprehensive OAuth 2.1 authorization framework, according to the official 2025-03-26 changelog. It was necessary, but it assumed the MCP server and authorization server shared an origin.

The client derived authorization endpoints by stripping the path from the MCP server URL. If the server lived at https://api.example.com/v1/mcp, the client looked for /authorize, /token, and /register at https://api.example.com.

That worked for a self-contained server. It worked poorly when an enterprise wanted its existing identity provider to issue tokens or when a resource used an independent authorization service. It also pushed every MCP server toward operating OAuth endpoints, client registration, consent, refresh tokens, and security policy.

The result blurred two roles OAuth keeps separate: the resource server protects the API; the authorization server obtains authority and issues tokens.

Protected-resource metadata fixed discovery

The June 2025 revision made the decisive change. The official 2025-06-18 changelog describes MCP servers as OAuth resource servers and adds protected-resource metadata for discovering their authorization servers.

RFC 9728 gives the resource a standard metadata document:

{
  "resource": "https://api.example.com/mcp",
  "authorization_servers": ["https://identity.example.net"],
  "scopes_supported": ["documents.read"]
}

The same revision required clients to send the RFC 8707 resource parameter. The authorization server can issue a token for the intended MCP server, and the server must reject tokens minted for another audience.

This also closed token passthrough. An MCP server cannot accept a token meant for a downstream API and forward it. It validates a token issued for itself, then uses a separate credential when it calls another service.

That is ordinary OAuth—and ordinary is a compliment.

DCR exposed an enterprise fault line

An MCP client may encounter a server whose operator has never seen that client. Early specifications relied on Dynamic Client Registration to create a client record at runtime.

DCR asks authorization servers to maintain an open-ended database of self-asserted metadata. Many enterprise identity providers do not expose a DCR endpoint at all.

Client ID Metadata Documents, or CIMD, invert registration. The client_id is an HTTPS URL that the authorization server dereferences:

client_id=https://client.example.com/oauth/metadata.json

The November 2025 MCP revision recommended CIMD. The July 2026 revision deprecated DCR in its favor. CIMD is now an adopted OAuth Working Group draft, draft-ietf-oauth-client-id-metadata-document, but it is not yet an RFC.

The trade-off moved rather than disappeared. DCR creates database and governance risk. CIMD creates network-fetch and SSRF risk. Authorization servers must restrict schemes, block private and metadata networks, limit redirects and response sizes, and cache carefully.

Issuer identification hardened multi-server clients

An MCP client can talk to many resources protected by different authorization servers. That makes mix-up attacks relevant: a client starts with one issuer but processes a response associated with another.

The July 2026 revision added RFC 9207 issuer identification. The authorization response includes iss, and the client compares it to the issuer selected before exchanging the code.

The same revision strengthened authorization-server binding of client credentials. These details prevent a multi-server client from sending a valid code or credential to the wrong party. See OAuth mix-up attacks and RFC 9207 for the attack path.

Enterprise authorization moved into an extension

MCP’s base authorization flow is user-directed. Enterprises also need centrally provisioned access without a separate consent ceremony for every server.

The Enterprise-Managed Authorization extension became stable on 18 June 2026. It uses an enterprise identity assertion and the emerging ID-JAG flow to broker cross-app access under organization policy.

That capability lives in an extension rather than distorting the base protocol. The July 2026 specification formalized an extension framework so enterprise authorization and other capabilities can evolve on their own schedules.

This is the second healthy pattern in MCP’s evolution: keep the interoperable core small, then put deployment-specific behavior behind explicit negotiation.

The current architecture is stronger, not finished

The current MCP authorization specification has a defensible division of responsibility:

MCP client
   │ discovers
   v
MCP resource server ── RFC 9728 ──> authorization server
   ^                                      │
   └──── audience-bound access token ─────┘

Its boundaries remain clear:

• OAuth 2.1 is still an Internet-Draft.
• CIMD is an OAuth Working Group draft.
• HTTP authorization is optional in MCP; stdio obtains credentials from its environment.
• Scopes express API permission, not a complete agent task.
• The base protocol does not solve recursive delegation or intent binding.

Those are reasons to build an authority layer above OAuth, not to invent another authentication protocol. OAuth solved agent access, but not agent authority explains that layer.

MCP improved because it stopped trying to be an identity provider. The next eighteen months should follow the same rule: reuse stable primitives, isolate experiments, and delete bespoke machinery when a standard catches up.