How does MCP authorization work?
In short: MCP authorization applies OAuth to tool access. The MCP server acts as a resource server, an authorization server issues tokens, and the client presents a token on each request. A gateway sits in front of servers as the enforcement point, checking tokens and policy before any call reaches a tool.
Who are the parties?
The MCP client is the OAuth client. The MCP server is the resource server. A separate authorization server issues access tokens.
Servers publish protected resource metadata so clients can find the right authorization server.
What does the client do?
When a request lacks a valid token, the server answers with a 401 and points to its metadata. The client then runs an OAuth 2.1 flow with PKCE and retries with the token.
What must the server check?
The server must validate that a token was issued for it, using audience binding. It must not accept tokens meant for other services, and it must not pass client tokens upstream.
Where does a gateway fit?
A gateway can act as the resource server for many MCP servers at once. It validates tokens, applies policy per tool call and fetches separate upstream credentials.
Our per-call authorization criterion asks whether that policy also knows the person the agent acts for.
Sources
- MCP spec: Authorization [mcp-auth] read 2026-11-03
- MCP spec: Security best practices [mcp-sec] read 2026-11-03
Other explainers are listed on the spec hub.
By The Datasheet desk · Published and reviewed 2026-11-03