What is MCP Authorization?

Authorization is optional in MCP, but implementations using an HTTP-based transport SHOULD conform to the specification; stdio servers should instead take credentials from the environment. The roles map directly onto OAuth 2.1: the MCP server is the resource server, the MCP client is the OAuth client, and a separate (or co-hosted) authorisation server issues tokens.

Discovery is fully automated. A request without a token gets a 401 whose WWW-Authenticate header (or a well-known URI) points to the server's Protected Resource Metadata (RFC 9728), whose authorization_servers field names at least one authorisation server. The client then fetches authorisation server metadata via RFC 8414 or OpenID Connect Discovery. For client registration, the current spec (2025-11-25) prefers pre-registered credentials, then Client ID Metadata Documents, with Dynamic Client Registration retained as a backwards-compatible fallback.

Several requirements exist purely for security: clients MUST use PKCE and MUST send the RFC 8707 resource parameter naming the target server, and servers MUST validate that tokens were issued specifically for them — the audience binding that makes token passthrough a forbidden anti-pattern. Servers SHOULD advertise required scopes in the WWW-Authenticate challenge, and clients follow least privilege with step-up authorisation when a call returns insufficient_scope.

For teams running many remote servers, the practical consequence is that authorisation is negotiated per server: each upstream has its own authorisation server, scopes, and consent flow, with no fleet-wide view of who can call what.

PolicyLayer sits in front of upstream MCP servers as a gateway, so client access is governed by per-person scoped tokens issued by PolicyLayer rather than by each upstream's individual OAuth posture. Every tools/call that arrives with a valid token is still evaluated against deterministic policy before it executes, giving a single authorisation and audit point across the fleet.