OAuth for MCP Servers: How AI Agent Authorization Actually Works (2026 Spec)

Spin up an MCP server with a default template and connect a client. It often works immediately, with no login, no token, no consent screen. That frictionless default is exactly the problem. The Model Context Protocol makes authorization optional, and the path of least resistance is to ship a server that any client on the network can call. Authorization in MCP is real, well-specified, and built on mature standards, but you have to opt into it, and a large share of servers in the wild have not.

This guide explains how OAuth for MCP servers actually works in the 2026 specification: the OAuth 2.1 baseline, the mandatory pieces (PKCE, resource indicators, audience validation), the rule that makes token passthrough a security bug, what the November 2025 revision changed, and the concrete controls a security team applies across a fleet of agents and MCP servers.

What MCP authorization actually is

The MCP authorization model is defined in the official specification (modelcontextprotocol.io) and is a profile of OAuth 2.1 (IETF draft-ietf-oauth-v2-1-13). It maps the three OAuth roles directly onto MCP components:

• The MCP server is the OAuth 2.1 Resource Server - it owns the protected tools and resources and validates incoming tokens.
• A separate Authorization Server (AS) issues tokens. It may be co-hosted with the resource server or be a separate entity; either way the MCP server delegates token issuance to it.
• The MCP client (the agent runtime, IDE, or CLI driving the model) is the OAuth 2.1 client that obtains and presents tokens.

Two scoping facts matter before anything else. First, authorization is optional overall - the protocol works without it. Second, it applies to the HTTP transport. Local stdio servers, which run as a child process on the same machine, retrieve credentials from the environment rather than running this OAuth flow; their risk profile is different and is covered in the MCP server security guide and in our note on why stdio MCP is RCE by design. The OAuth model below is about remote, network-reachable MCP servers.

The crucial nuance: optionality is about whether you adopt authorization, not how. The moment an HTTP MCP server supports OAuth, the spec stops using SHOULD and starts using MUST. There is no half-compliant tier.

How the OAuth flow works, step by step

When a compliant client first hits a protected MCP server, the flow discovers where to authenticate and then binds the resulting token to that one server:

1. The client calls the MCP server without a token. The server responds 401 Unauthorized, ideally returning a WWW-Authenticate header whose resource_metadata parameter points at its Protected Resource Metadata (PRM).
2. The client fetches the PRM document (RFC 9728), which names the authorization server(s) the MCP server trusts. If the header is absent, the client falls back to the .well-known/oauth-protected-resource URI.
3. The client fetches the AS metadata (RFC 8414 or OpenID Connect Discovery) to find the authorization and token endpoints, and verifies PKCE support.
4. The client runs the OAuth 2.1 authorization-code flow with PKCE (RFC 7636), sending the resource parameter (RFC 8707) set to the canonical MCP server URI in the authorization request.
5. At the token endpoint the client again presents the resource parameter, and the AS mints an access token whose audience is that specific MCP server.
6. The client calls the MCP server with the token. The server validates the audience is itself and only then serves the request.

Every link in that chain corresponds to a MUST in the spec. Here is the mandatory control set.

The mandatory pieces (and the RFCs behind them)

Read that table as a compliance checklist, because that is exactly how it functions. A server that returns tool listings without a token fails at row one. A server that accepts any valid-looking bearer token regardless of audience fails the last row, which is one of the two confused-deputy failure modes below.

Resource indicators and audience binding: the core defense

The single most important concept for OAuth on MCP servers is token-to-server binding via RFC 8707. The client declares, in both the authorization and token requests, the canonical URI of the MCP server it intends to call - for example https://mcp.example.com/mcp. The AS encodes that as the token's audience. The MCP server then refuses any token whose audience is not itself, validating the audience claim as described in RFC 9068 and OAuth 2.1 Section 5.2.

Without this, a token issued for a low-value MCP server could be replayed against a high-value one that shares the same authorization server. Resource indicators turn a broadly usable bearer token into a single-target credential. This is also why MCP tokens are a flavor of non-human identity that needs its own governance - they are machine credentials with audience, scope, and lifetime that someone has to track.

The forbidden move: token passthrough and the confused deputy

The spec is unusually blunt here: "The MCP server MUST NOT pass through the token it received from the MCP client." Token passthrough is when a server takes the access token a client presented and forwards that same token, unmodified, to a downstream API to make a call on the user's behalf.

Why is that a privilege-escalation bug? Because the downstream API may now trust a token that was never validated or issued for it. The MCP server becomes a confused deputy - a privileged intermediary tricked into wielding its trust relationship on an attacker's behalf. The spec names two distinct failure dimensions:

• Audience-validation failure - the server accepts tokens minted for other resources, so a token meant for service B is honored by server A.
• Token passthrough - the server forwards the client's unmodified token to an upstream API, which then treats it as authoritative.

The correct pattern is unambiguous: an MCP server that needs to call an upstream API must act as its own OAuth client to that API and obtain a separate token, scoped for that call, rather than reusing the client's token. Proxy-style servers that present a static client ID to multiple downstream services carry extra obligations - they MUST obtain explicit user consent per dynamically registered client, so one user's prior consent cannot be silently reused for another.

This is not theoretical. The confused-deputy pattern in MCP is the same shape as the GitHub MCP issue documented by Invariant Labs in May 2025, where an agent with access to both public and private repositories was steered by a malicious public issue into exfiltrating private-repo data - the agent reused a single token spanning both scopes. It also maps cleanly onto Simon Willison's lethal trifecta - private data access, exposure to untrusted content, and outbound communication. An over-permissioned, passthrough MCP server can combine all three, which is why we treat it as a data-exfiltration vector in the lethal trifecta analysis and in the indirect prompt injection explainer.

What the two big spec revisions changed

Two revisions shaped the model you should implement today.

June 2025 (2025-06-18): the security hardening

This was the pivotal revision. It reclassified the MCP server as an OAuth 2.1 Resource Server, made RFC 9728 Protected Resource Metadata mandatory for authorization-server discovery, and introduced the resource-indicator and audience-binding requirements - the RFC 8707 plus audience-validation pairing that closes the confused-deputy gap. If you only adopt one revision's worth of changes, this is the one that matters for security.

November 2025 (2025-11-25): registration and ergonomics

Verified against the official 2025-11-25 specification, this revision refined how clients register and discover, without weakening the June MUSTs:

• Client ID Metadata Documents (CIMD) became the recommended client-registration mechanism, ahead of Dynamic Client Registration (RFC 7591), which is retained for backwards compatibility. CIMD lets a client be identified by an HTTPS URL pointing at its metadata document, removing the need for pre-registration.
• Authorization-server discovery now requires both RFC 8414 and OpenID Connect Discovery 1.0 support on the client side, with a defined priority order for probing well-known endpoints.
• PRM discovery offers a .well-known fallback, so clients use the resource_metadata value from the WWW-Authenticate header when present and otherwise probe the well-known URIs.
• Step-up (incremental) scope authorization was formalized via 403 insufficient_scope WWW-Authenticate challenges, letting a server request additional scopes mid-session rather than demanding everything up front.
• The same release also shipped Cross App Access (XAA) and URL-mode elicitation as broader protocol features beyond the authorization profile.

The takeaway for a security team: the protocol is converging on solid standards, but the standards still only apply to servers that opted into auth in the first place - and they evolve, so a server compliant in mid-2025 may use a now-superseded registration default.

Why so few MCP servers comply

The optional default is not an academic concern. Public measurement keeps finding large populations of exposed, unauthenticated MCP servers:

• Knostic (July 2025) identified 1,862 internet-exposed MCP servers; every one of the 119 samples they manually verified granted unauthenticated access to the full tool listing via a read-only tools/list request.
• Censys (scan window late April 2026) found 12,520 internet-accessible MCP services across 8,758 unique IPs, growing past 21,000 by early May 2026, and explicitly noted that MCP does not require authentication by default. Censys reported that roughly 40% of these services had no authentication at all; among those that did authenticate, about 53% relied on static API keys and only around 8.5% used OAuth with short-lived tokens.
• VIPER-MCP (arXiv 2605.21392, May 2026) scanned 39,884 real-world MCP server repositories and reported 106 zero-day vulnerabilities confirmed with end-to-end exploit traces, with 67 CVE IDs assigned - evidence that insecurity goes well beyond just missing auth.

The Censys breakdown is the directly measured picture: the default is no auth, and where auth exists it is usually a long-lived static key rather than the audience-bound, short-lived OAuth token the spec is built around. The implication for governance is the same either way - the spec is sound, but the deployed reality lags far behind it.

Concrete controls a security team applies

Translating the spec into fleet practice, here is the work that closes the gap.

1. Inventory every MCP server first

You cannot assess OAuth posture on servers you have not found. Build a complete inventory of MCP endpoints - internal, internet-facing, and developer-launched - before anything else. This is the same discipline as building an AI agent inventory and standing up an MCP server registry; without it, every later control has blind spots.

2. Assess each server against the MUSTs

For every discovered server, record whether it: enforces auth at all; serves RFC 9728 PRM; uses PKCE in its client flow; validates token audience; and avoids token passthrough. Flag the unauthenticated, the static-API-key-only, and the passthrough servers as your highest-priority remediation queue.

3. Enforce least privilege on tokens and tools

Audience-bound tokens are necessary but not sufficient - scope still matters. Apply least privilege for AI agents so an MCP token grants only the tools and data the workflow needs, and keep upstream credentials out of the passthrough path by managing them as described in secrets management for AI agents.

4. Monitor tokens crossing service boundaries

Audience validation is a static control; you also want runtime signal. Watch for tokens being presented to servers they were not minted for, for servers forwarding client tokens upstream, and for anomalous tool-call patterns. That is the role of runtime monitoring and anomaly detection for AI agents, feeding an audit trail you can actually investigate.

5. Map to your governance frameworks

The confused-deputy and passthrough risks line up with documented agentic threats - see the OWASP Top 10 for agentic applications and MITRE ATLAS for agentic AI - which helps you justify the controls to GRC and tie them to existing audit obligations.

Where continuous MCP visibility fits

Every control above depends on one precondition: knowing which MCP servers exist and what their authorization posture is, continuously, not as a one-time audit. Because the protocol makes auth optional and developers launch servers faster than reviews happen, the population drifts. A server that was internal yesterday is internet-facing today; a new template reintroduces passthrough next sprint.

This is the category Anomity works in: discovering and inventorying every AI agent and MCP server across the fleet, then assessing each against the MCP authorization MUSTs - no PKCE, no PRM, missing audience validation, token passthrough - and alerting when posture regresses. It is the same principle that runs through our work on shadow IT in the AI era: you cannot govern what you cannot see. The OAuth spec gives you the rules; visibility tells you which of your servers are actually following them.

Bottom line

OAuth for MCP servers is a well-built profile of OAuth 2.1 with a clear, mandatory control set: PKCE, RFC 9728 PRM, RFC 8414 or OpenID Connect Discovery AS metadata, RFC 8707 resource indicators, audience validation, and an absolute prohibition on token passthrough. The standards are not the weak point. The weak point is that the protocol makes adopting them optional, and the measured reality is a large population of unauthenticated or static-key-only servers. Implement the MUSTs on the servers you control, and put continuous discovery and posture assessment in front of the fleet so the gap cannot quietly reopen.