In MCP, what OAuth 2.1 role does a remote server play, and what does it do with a token?

## The three OAuth 2.1 roles, and which one MCP takes OAuth 2.1 separates three parties. The **client** is the application asking for access — here, the MCP client inside the host application. The **authorization server** (AS) authenticates the end user, obtains their consent, and mints access tokens. The **resource server** (RS) holds the protected functionality and does nothing but check the tokens presented to it. A remote MCP server, in revision 2026-07-28 of the specification, is a resource server and only a resource server. It does not render a login page, does not verify passwords or second factors, does not mint, refresh or revoke tokens, and never sees the user's credentials. It receives an access token that somebody else issued and decides — on this request, right now — whether that token authorizes this call. ## Why the specification draws the line there Putting identity in the MCP server would mean every server author reimplements login, consent, MFA, token lifetime and revocation. Delegating to an existing authorization server means an operator can put an MCP server in front of an internal API and reuse the identity provider the organization already runs. It also keeps the blast radius small: a compromised MCP server leaks whatever data it fronts, but cannot mint credentials for anything. ## What the server actually does with the token On each request the server must establish four things. 1. **Integrity and origin** — the token really was issued by an authorization server this resource server trusts (verify the signature against the AS's keys, or call an introspection endpoint). 2. **Freshness** — it has not expired and is not used before its validity window. 3. **Audience** — the token was issued *for this MCP server*. MCP's profile is explicit that a server must reject a token that was not issued for it; accepting somebody else's token is the token-passthrough antipattern. 4. **Authorization** — the scopes or claims in the token cover the operation being attempted. The HTTP answers follow ordinary bearer semantics: `401` when no usable credential was presented, `403` with `error="insufficient_scope"` when the caller is authenticated but under-privileged for that particular call. ## Authorization is per request, not per connection This is where MCP differs from the mental model most people carry over from older client-server protocols. Revision 2026-07-28 made MCP a stateless protocol: the `initialize` handshake and the protocol-level session (with its `Mcp-Session-Id` header) that existed through 2025-11-25 were both removed. There is nothing to "log into". Each POST to the MCP endpoint carries its own protocol version and capabilities in `params._meta` and its own `Authorization` header, and a server must not rely on a previous request over the same connection to establish who is calling. Two practical consequences follow. First, any node behind a load balancer can serve any request, so token validation must be cheap and independent — cache the authorization server's signing keys rather than round-tripping introspection per call. Second, while the tool, prompt and resource sets a server exposes must not vary per connection, they *may* vary by the authorization presented — a token with fewer scopes may legitimately see a smaller `tools/list`. ## Which servers this applies to The OAuth profile is transport-level and HTTP-only. A stdio server is a local subprocess the host launched; there is no HTTP request to attach a bearer token to, and it takes whatever credentials it needs from its own environment. When an interviewer asks "how does an MCP server authenticate callers", the first move is to ask whether the server is local or remote. ## What a remote MCP server is not It is not an authorization server, so it should not be growing its own user table. It is not a token issuer. It must not accept a token minted for a different audience just because the token verifies. And it must not take the caller's token and replay it to an upstream API — when the MCP server needs to call something downstream, it uses credentials of its own, obtained separately.