MCP Authorization Server vs. Resource Server Separation is the architectural pattern the MCP specification recommends for production OAuth 2.1 deployments. The authorization server handles user authentication, consent, and token issuance. The resource server (the actual MCP server) handles tool calls, resource reads, and prompt invocations, validating tokens on every request but never issuing them.
The June 2025 MCP spec revision formally split these two roles and standardized discovery through Protected Resource Metadata (RFC 9728). The separation is optional per the OAuth 2.1 spec but is considered best practice in MCP because it reduces attack surface, simplifies token validation, and lets one authorization server protect many MCP resource servers.
How the Separation Works in an MCP Deployment
The MCP resource server hosts only MCP endpoints and a PRM document. When a client makes an unauthenticated request, the server returns 401 with a WWW-Authenticate: MCP header pointing to the PRM. The PRM lists the authorization server URL. The client runs the full OAuth 2.1 flow with the authorization server, obtains a token, and returns to the MCP resource server with the token attached. The resource server validates the token signature, audience, scope, and expiration on every request. It never sees user credentials, never issues tokens, and never handles consent UI
Certified MCP Security Expert
Attack, defend, and pen test MCP servers in 30+ hands-on labs. Get certified.
Why MCP Recommends This Separation
Mixing authorization and resource concerns in one server creates a larger attack surface. A vulnerability in the OAuth flow becomes a vulnerability in the data plane. Patching the OAuth implementation requires touching the same code that handles tool calls. Separation lets each component operate independently. The authorization server can rotate signing keys, add new grant types, and update consent UI without touching MCP servers. The resource server can ship new tools and resources without re-implementing OAuth. The separation also enables one authorization server to protect dozens of MCP servers, which is impossible with embedded auth.
How to Implement the Separation Correctly
Pick a battle-tested authorization server: Keycloak, Auth0, Okta, Ory Hydra, or a managed equivalent. Configure it to issue audience-scoped tokens using resource indicators (RFC 8707). On the MCP resource server, validate every incoming token’s signature, aud claim, scope, and expiration. Cache the authorization server’s signing keys but rotate them automatically. Implement Protected Resource Metadata (RFC 9728) so clients can discover the authorization server through the WWW-Authenticate: MCP header.
Summary
Separating the MCP authorization server from the MCP resource server is the production-grade pattern the MCP spec recommends. One authorization server can protect many MCP resources, and each component operates independently without expanding the attack surface. The Certified MCP Security Expert (CMCPSE) certification trains engineers to design separated MCP architectures using Keycloak, Auth0, or any modern OAuth 2.1 authorization server.