TRACK: AI AGENTS AND MCP

How MCP authorization works

Editorial assessment · Desk research from public vendor material · Reviewed 2026-09-29

2 min read

Authorization in the Model Context Protocol is optional, but when an MCP server is reached over HTTP the specification describes how it should work. It reuses OAuth rather than inventing something new.

The three parties

The MCP client is the agent or application making calls. The MCP server exposes the tools and acts as an OAuth 2.1 resource server. The authorization server issues tokens; it can be run by the same party as the MCP server or by someone else.

The flow

1. The client calls the MCP server without a token and receives a 401 response with a pointer to the server's Protected Resource Metadata.
2. The client reads that metadata to find the authorization server, then reads the authorization server's own metadata.
3. The client may register itself dynamically, then starts an authorization request using PKCE and a resource parameter naming the MCP server.
4. The user approves, the client exchanges the code for an access token, and sends it in the Authorization header on every request.
5. The MCP server checks that the token was issued for it before doing anything.

The rule that matters most

An MCP server must not accept tokens issued for anything else, and must not pass a token it received on to another API. If it needs to call an upstream service, it gets a separate token for that service. The specification's security page explains why: passing tokens through bypasses the downstream system's controls and makes it impossible to tell who actually made a request.

See MCP gateways compared