At A Glance
- MCP shipped with no authorization framework in November 2024. By the July 2026 revision, it reads as a recognizable OAuth 2.1 and OpenID Connect profile.
- The current model treats the MCP server as a resource server, separates it from the authorization server that issues tokens, and binds every token to its intended audience.
- The standard is strong, but real deployments lag it. Token passthrough, risky client registration, and skipped audience checks remain common, which is where Zero Trust connectivity complements application-layer auth.
Every AI agent that reaches a tool or a data source does it through a connection, and the Model Context Protocol (MCP) has become the connection most of them use. That reach created a problem the early spec barely addressed: who is calling, and are they allowed in? When MCP first shipped in November 2024, it had no authorization framework at all. Eighteen months later, MCP authentication and authorization look like a recognizable enterprise OAuth profile. The standard matured quickly. Putting it into production correctly is still the hard part, and that work lands on whoever deploys the server.
How MCP Auth Grew Up
The arc is short and steep. The March 2025 revision introduced an authorization framework built on OAuth 2.1, with PKCE required for all clients. The June 2025 revision did the heavy lifting, recasting the MCP server as an OAuth resource server; separating it from the authorization server that issues tokens; making Protected Resource Metadata (RFC 9728) mandatory; requiring Resource Indicators (RFC 8707); and prohibiting token passthrough outright. The November 2025 revision added OpenID Connect Discovery, incremental scope consent, and recommended Client ID Metadata Documents for registering clients. The current revision, dated July 2026, moves MCP closer to standard OAuth 2.0 and OpenID Connect practice, deprecates Dynamic Client Registration in favor of Client ID Metadata Documents, and adds issuer validation to blunt mix-up attacks. In roughly 18 months, MCP went from no auth story to a profile an enterprise identity team can actually recognize.
What Good Looks Like Today
The recommended model divides the work cleanly. The MCP server acts as a resource server. It validates tokens and enforces permissions, and it does not handle logins or mint tokens of its own. A separate authorization server, usually the enterprise identity provider, authenticates the user and issues a token scoped to that specific server. Discovery ties the two together: when a client calls without valid credentials, the server returns a 401 with a WWW-Authenticate header that points to its metadata, and that metadata names the authorization server the client should use. Resource indicators finish the job by binding each token to its intended audience, which stops a token minted for one server from being replayed against another. None of this is exotic. It is OAuth 2.1 and OpenID Connect applied to a new kind of client, which is exactly why it has settled so quickly.
Where It Still Breaks
A strong standard does not make a given deployment safe. The clearest example is token passthrough and the confused-deputy problem behind it. A server that forwards the client’s token to an upstream API lets that downstream service trust a credential it was never meant to see. The spec now forbids this, yet plenty of servers built before June 2025 still do it. Dynamic Client Registration carries its own risk because anonymous registration lets an attacker impersonate a legitimate client, which is why the standard is backing away from it. The deeper issue is the gap between the spec and the field. Many deployed servers run older revisions or skip the demanding parts, such as audience validation and tight scoping. SaaS vendors, open-source servers, and internal tools all sit at different points on the timeline, so “MCP supports OAuth” tells you little about whether the server in front of you is actually locked down.
Who’s Calling Is a Network Question too
Treat every MCP server as an identity-bearing resource rather than a convenience. Confirm which spec revision it implements, verify that tokens are audience-bound, and refuse any server that passes tokens through. Application-layer auth answers whether a request carries a valid token. It does not answer whether the agent should be able to reach that server in the first place. That second question is a Zero Trust networking question, and it is where identity-verified, least-privilege connectivity earns its place. If you can’t control the agent, you must control what it can reach. An overlay that makes services invisible by default, and reachable only by verified identities, means a stolen or misused token still has nowhere to go. MCP authentication and Zero Trust connectivity work best as layers, not substitutes.
Frequently Asked Questions
Does MCP use OAuth?
Yes. Since the March 2025 revision, MCP authorization has been built on OAuth 2.1, with PKCE required for clients. Later revisions added OpenID Connect Discovery and moved the profile closer to standard OAuth 2.0 and OpenID Connect deployment practice.
What is token passthrough, and why does the spec ban it?
Token passthrough is when an MCP server forwards the token it received from a client to an upstream API instead of obtaining its own. It creates a confused-deputy risk because the downstream service ends up trusting a credential that was never issued for it. The June 2025 revision prohibits it outright.
Is Dynamic Client Registration still recommended?
No. Anonymous registration makes client impersonation easier, so the current revision deprecates Dynamic Client Registration in favor of Client ID Metadata Documents, where a client’s identifier is an HTTPS URL to hosted metadata.
Does MCP authentication replace network security?
No. MCP auth validates whether a request carries a valid, correctly scoped token. It does not decide whether an agent should be able to reach a given server at all. Zero Trust connectivity handles that second question by making services reachable only to verified identities, so the two operate as complementary layers.
