Remote Servers and Authorisation

Remote means real authentication

A local stdio server runs as the user, but a remote server is a network service that may hold other people's data, so it needs proper authentication and authorisation. The MCP specification builds on OAuth 2.1: the server acts as a protected resource, the client obtains an access token from an authorisation server after the user consents, and sends it as a Bearer token with each request; tokens are short-lived, scoped to what is needed and bound to the intended server (audience). Do not pass a client's token through to other downstream APIs (the "confused deputy" problem); exchange or issue separate credentials. Always use HTTPS, validate the Origin header for local HTTP servers, and rate-limit. The authorisation details have evolved across spec versions, so follow the current specification.

The authorisation flow in words

A simplified sequence; details vary with the spec version.

1. client calls the MCP server without a token  -> 401 + pointer to its authorisation server
2. client discovers the authorisation server and registers / identifies itself
3. user is sent to sign in and approve the requested scopes (consent)
4. client receives a short-lived access token (audience = this MCP server)
5. client sends   Authorization: Bearer <token>   on every request
6. server validates signature, expiry, audience, scopes -> else 401/403
7. server must NOT forward this token to other APIs; it uses its own credentials

Least scope, shortest lifetime

Ask for the narrowest scopes that work, and use short token lifetimes with refresh, so a leaked token does limited damage.

Quick check: Why must an MCP server not forward the client's token to other APIs?

• It would be a confused-deputy risk and breaks audience binding
• Tokens are too long
• APIs cannot read tokens
• It speeds up requests