If you've added authentication to an MCP server in the last year, you've felt a discontinuity that the tutorials rarely name. The early guidance treated the server as the thing that logs users in. The current guidance treats it as the thing that politely declines to. Somewhere between two spec revisions, the Model Context Protocol changed its mind about what an MCP server is in an authorization flow — and the change is worth understanding, because it dictates exactly one parameter your client now has to send, and that parameter is the whole security argument.

The pivot: from gatekeeper to bouncer

The Model Context Protocol's first OAuth-2.1-based authorization framework shipped in the 2025-03-26 revision. In it, an MCP server could be both the OAuth resource server (the thing that holds the protected tools and data) and the OAuth authorization server (the thing that issues tokens). One service did both jobs: it logged you in and it served you.

The 2025-06-18 revision pulled those two jobs apart. An MCP server is now defined as a plain OAuth 2.1 resource server — full stop. It accepts access tokens and validates them; it does not issue them. Issuing is delegated to a separate authorization server, which in practice is whatever identity provider you already run. The server's only job at the door is to check the token and either serve the request or return a 401.

That sounds like bureaucratic reshuffling. It is actually the load-bearing decision, because it forces the server to answer a question it never had to ask when it minted its own tokens: was this token issued for me, specifically?

An MCP server stopped being the place you log in and became the place that checks whether the login you're carrying was meant for this door — and no other door that trusts the same key-cutter.

To make delegation discoverable, the server advertises its authorization server with Protected Resource Metadata (RFC 9728): a document at /.well-known/oauth-protected-resource that the client reads to learn where to go get a token. In the 2025-06-18 revision the server was also required to point there via a WWW-Authenticate header on its 401 responses; the current 2025-11-25 revision relaxed that to "implement one of" the header or the well-known URL. Worth pinning the revision when you cite it — this part moved.

The linchpin: one parameter, audience-bound

Here is the parameter everything hinges on. MCP clients MUST implement RFC 8707 Resource Indicators — meaning every authorization request and every token request carries a resource parameter that names the exact MCP server the token is for. The client must send it "regardless of whether the authorization server supports it."

The reason is a specific, nasty failure mode. Without audience-binding, a token is a bearer of authority with no opinion about where it's spent. If three MCP servers in your stack all trust the same authorization server, a token your client obtained for the calendar server is, by default, a token the email server will also happily accept. Compromise one server, replay its tokens against the others. Resource Indicators kill that: the resource parameter binds the issued token to a single audience, so the email server, checking the audience claim, sees a token addressed to the calendar server and rejects it.

The honest nuance — the one that separates a working implementation from a checkbox — is that the binding only enforces when both halves are present. The client must send resource (a MUST), and the authorization server must actually honor it by stamping the audience, and the resource server must validate that audience and reject mismatches. The spec qualifies its own promise carefully: Resource Indicators provide their security benefit "when the authorization server supports the capability." Send the parameter and assume you're safe, against an authorization server that ignores it, and you've shipped the vulnerability with extra steps.

The prohibition that makes it stick: no token passthrough

Audience-binding only matters if servers refuse to launder tokens, so the spec's Security Best Practices add a blunt rule in its Token Passthrough section: an MCP server MUST NOT accept any token that was not explicitly issued for it, and it must reject tokens whose audience claim doesn't include it. A second rule closes the upstream side: a server MUST NOT pass the token it received from the client through to a downstream API. If it needs to call something on the user's behalf, it performs a token exchange to get a fresh, correctly-scoped token — it does not forward the one it was handed.

Together these defuse the confused deputy: a server with legitimate authority being tricked into spending that authority for an attacker. A proxy that forwards tokens is the textbook deputy, which is why the spec separately requires MCP proxy servers to obtain explicit per-client consent rather than riding on a single upstream authorization.

The implementer's checklist

Strip the protocol archaeology away and the current model is short enough to hold in your head. If you operate an MCP server:

And if you write the client: send the resource parameter, every time, on both legs of the flow. It is one field in a query string. It is also the difference between a token that means "the bearer may use this one server" and a token that means "the bearer may use anything that trusts this issuer" — which is the difference the whole 2025 redesign exists to draw.

This is the authorization layer underneath everything else MCP does — the transport you pick decides how messages move; this decides who's allowed to send them, and to which door.