OAuth Protected Resource Metadata in MCP

OAuth Protected Resource Metadata is a small JSON document an MCP server publishes so AI apps know where to sign in. Its most important field, authorization_servers, lists the authorization server that issues tokens for that MCP server. It is defined by RFC 9728, and the MCP spec makes it mandatory for protected servers.

Status in the 2026-07-28 spec: core (required for MCP servers that implement authorization)

Think of it as the sign on the door that says "get your badge at reception, over there." This page follows the authorization server discovery page of the 2026-07-28 spec and RFC 9728 itself, both checked on 28 October 2026.

Why it exists

An AI app may connect to an MCP server it has never seen. It needs to learn, with no prior setup, which authorization server to talk to and which scopes to ask for. Before 2025-06-18, MCP had no standard way to say this, and the 2025-03-26 authorization page told clients to fall back to default paths such as /authorize on the server's own domain.

The 2025-06-18 changelog fixed this. It classified MCP servers as OAuth resource servers, "adding protected resource metadata to discover the corresponding Authorization server." That lets a company keep its MCP server and its identity provider on different hosts.

RFC 9728 itself is an IETF Standards Track document published in April 2025. It defines "a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource."

How it works

Step 1: The client finds the document

The 2026-07-28 spec says MCP servers "MUST implement one of the following discovery mechanisms":

1. The WWW-Authenticate header. On a 401 Unauthorized, include the document URL in a resource_metadata parameter.
2. A well-known URI. Serve the document either at the path of the MCP endpoint or at the root. For https://example.com/public/mcp, that means https://example.com/.well-known/oauth-protected-resource/public/mcp or https://example.com/.well-known/oauth-protected-resource.

Clients "MUST support both discovery mechanisms." They use the header URL when present. Otherwise they "MUST fall back" to the well-known URIs, path-based first, then root.

Step 2: The client reads the document

RFC 9728 defines the fields. Here is a document for an MCP server, adapted from the RFC's example response:

{
  "resource": "https://mcp.example.com/mcp",
  "authorization_servers": ["https://auth.example.com"],
  "scopes_supported": ["files:read", "files:write"],
  "bearer_methods_supported": ["header"],
  "resource_name": "Example Files MCP Server",
  "resource_documentation": "https://example.com/docs/mcp"
}

MCP tightens the RFC in one place. The RFC makes authorization_servers optional, but the MCP spec says the document "MUST include the authorization_servers field containing at least one authorization server."

The MCP spec also gives scopes_supported a meaning. It is "intended to represent the minimal set of scopes necessary for basic functionality," with extra scopes requested later through step-up.

Step 3: The client validates it

RFC 9728 Section 3.3 says "the resource value returned MUST be identical" to the identifier used to build the well-known URL. If the document came from a WWW-Authenticate link, the resource must equal the URL the client called. "If these values are not identical, the data contained in the response MUST NOT be used." The RFC says this can "thwart impersonation attacks."

Step 4: The client picks an authorization server

If several are listed, "each is an independent OAuth 2.0 authorization server," and the client chooses. Clients "MUST maintain separate registration state" per authorization server. The client then fetches that server's own metadata, as described in MCP authorization: what the spec requires.

What changed across spec versions

The 2026-07-28 changelog adds that when the authorization server changes, detected through updated metadata, clients "MUST re-register." Client ID Metadata Documents are the exception, since they are portable. See Client ID Metadata Documents in MCP.

Common mistakes

• Leaving out authorization_servers. RFC 9728 allows it; MCP does not.
• A resource value that does not match the URL. Clients must discard the document. Watch trailing slashes and paths.
• Serving metadata only at the root when the MCP endpoint has a path, and not sending the header. Clients try the path-based URL first.
• Listing offline_access in scopes_supported. The MCP spec says servers "SHOULD NOT," because refresh tokens are not a resource requirement.
• Publishing every scope you have. Keep scopes_supported to the minimum, as the spec intends.

More examples sit in common MCP OAuth misconfigurations.

Next step

Once the client knows the authorization server, it has to identify itself. Read Client ID Metadata Documents in MCP next, or browse the MCP specification reference.

Frequently asked questions