What is MCP Authorization?
Model Context Protocol authorization is the process that lets an MCP client obtain and present an access token for a remote MCP server. Authorization is optional in the protocol and applies to HTTP transports. The current specification uses OAuth metadata and resource indicators so the token is issued for the intended protected resource. Local stdio connections use a different process and credential boundary.
Why it matters
An MCP server can expose tools that read data or change systems. Remote clients need a token that is valid for the intended server, and the server still needs policy for each permitted method, tool, and downstream resource.
How it works
- The remote MCP server publishes protected-resource metadata that identifies the authorization server and the protected resource. The protocol requires this Protected Resource Metadata (PRM) document for authorization-server discovery.
- The client obtains an access token for that resource and presents it on the Streamable HTTP request. The protected resource validates the token, audience, and granted scope.
- The gateway and MCP server apply their own authorization. A scope challenge can request more permission, but the client must still obtain a valid token before it retries.
- For a client without preregistered credentials, Client ID Metadata Documents (CIMD) are the preferred registration method when the authorization server supports them. The client ID is an HTTPS URL for the client's metadata.
- Dynamic Client Registration (DCR) is deprecated and remains only as a backward-compatible fallback when the authorization server does not support CIMD.
Example
An MCP client discovers the authorization metadata for a private server and obtains a token for that server. Pomerium authenticates the caller, applies route policy, and permits only approved tools/call requests for the caller's group. The tool still applies its own data permissions.
Pomerium boundary
Pomerium can protect Streamable HTTP MCP server routes, manage documented upstream OAuth flows, maintain per-user upstream connections, and apply identity and mcp_tool policy. Pomerium can also issue an External Token for a delegated application flow. The protected MCP server and each tool keep their own resource authorization.
Limits and non-claims
- MCP authorization is optional at the protocol level. A deployment must choose and configure it for remote HTTP access.
- The MCP authorization specification does not secure local stdio processes or their environment credentials.
- Pomerium's mcp_tool criterion applies only to tools/call. It does not authorize every MCP method or the tool's internal data operations.
- OAuth authorization does not prove that a tool action is safe or that model output is correct.
Evaluation checklist
- Confirm the MCP transport. Use the MCP authorization flow for remote HTTP and a local credential boundary for stdio.
- Verify protected-resource metadata, authorization-server metadata, resource indicators, token audience, and redirect URIs.
- Separate route access, MCP method access, tool-name policy, and the tool's own resource authorization.
- Treat logged tool parameters as sensitive when observability includes them.
