# Remote Servers and Authorisation — MCP & Agent-to-Agent Protocols

Source: https://www.geekswithgeeks.com/en/mcp-a2a/c-remote-auth

> Protect remote MCP servers with proper OAuth-style 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.

```text
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.

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

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

*Answer:* It would be a confused-deputy risk and breaks audience binding. Tokens are meant for one audience; forwarding them lets services act with authority they were not given.