Protected Resource Metadata (PRM), defined in RFC 9728, is the discovery mechanism that lets MCP clients find out which authorization server protects a given MCP server. When an MCP client makes an unauthenticated request, the server responds with 401 Unauthorized and a WWW-Authenticate: MCP header pointing to its PRM document. The client fetches that document, reads the authorization_servers field, and discovers the URL of the OAuth 2.1 authorization server it needs to talk to. PRM solved a real problem in the MCP June 2025 spec revision, which formally split resource servers from authorization servers. Without PRM, clients had no standard way to find the right auth endpoint for any given MCP server.
How Protected Resource Metadata Works in MCP
The MCP server hosts a metadata document at a well-known path, typically /.well-known/oauth-protected-resource. The document is a JSON object containing fields like authorization_servers (array of authorization server URLs), bearer_methods_supported (typically [“header”]), resource_documentation, and signed_metadata. When a client receives 401, the WWW-Authenticate header points to this document with a resource parameter. The client fetches the document, picks an authorization server, and starts the OAuth 2.1 flow. Once it has a token, every subsequent request to the MCP server includes the token in the Authorization header.
Certified MCP Security Expert
Attack, defend, and pen test MCP servers in 30+ hands-on labs. Get certified.
Why PRM Matters for MCP Security Architecture
PRM enables the clean separation between the authorization server and resource server that the MCP spec recommends. Before RFC 9728, MCP servers had to either host their own OAuth endpoints (mixing auth and resource concerns) or hard-code the auth server URL into client configuration. PRM lets a single authorization server protect many MCP servers without static configuration. It also enables proper audience binding: each MCP server advertises its own resource identifier, which the authorization server uses to issue audience-scoped tokens. Without PRM, audience validation is nearly impossible to do correctly at scale.
How to Implement PRM Correctly
Host the metadata document over HTTPS only and validate the certificate chain on the client side. Sign the metadata document where possible to stop attackers from rewriting it via DNS hijack or proxy attacks. Include only authorization servers you actually trust in the authorization_servers field. Return a clear WWW-Authenticate header on every 401 response. Cache the metadata client-side but check for changes periodically. Audit every PRM fetch for forensic visibility.
Summary
Protected Resource Metadata (RFC 9728) is the discovery document MCP clients use to find the right OAuth authorization server for any given MCP server, enabling clean resource/authorization separation and proper audience binding. Sign it, serve it over HTTPS, and audit fetches. The Certified MCP Security Expert (CMCPSE) certification trains engineers to design PRM-driven discovery flows that scale across multi-server MCP deployments.