Reading RFC 9728

What RFC 9728 Is

RFC 9728 (Protected Resource Metadata) defines how an OAuth-protected resource server advertises its authorization server(s) to clients. For MCP, this is the discovery mechanism that allows agents to find the right authorization server without any configuration.

Before RFC 9728, a client needed to know out-of-band which authorization server to use. With RFC 9728, the MCP server tells the client where to go. The client can walk into any MCP server it has not seen before and know exactly how to authenticate.

The Well-Known URL

RFC 9728 defines a standard discovery URL path: /.well-known/oauth-protected-resource. An MCP server that implements the spec exposes a metadata document at this URL. No authentication required to fetch it — it is a public advertisement.

GET /.well-known/oauth-protected-resource HTTP/1.1
Host: api.yourmcpserver.example.com

The response is a JSON document:

{
  "resource": "https://api.yourmcpserver.example.com",
  "authorization_servers": [
    "https://auth.yourdomain.example.com"
  ],
  "scopes_supported": [
    "tools/read_db",
    "tools/write_db"
  ],
  "bearer_methods_supported": ["header"]
}

The Key Fields

resource: The canonical identifier for the protected resource. This becomes the aud (audience) claim in access tokens. When a token is issued, the authorization server sets aud to this value. The MCP server verifies that the token audience matches its identifier. This prevents token substitution attacks — a token issued for one MCP server cannot be used at another.

authorization_servers: The list of OAuth 2.1 authorization servers that can issue tokens for this resource. The client picks one and initiates the OAuth flow. AuthPlane MCP Auth is the authorization server you would list here.

scopes_supported: The scopes available on this resource. By convention for MCP, scopes are named tools/tool_name. This is what appears in the user consent screen when an agent requests access.

How AuthPlane Implements RFC 9728

AuthPlane handles both sides. For the authorization server side, AuthPlane exposes its own metadata document at /.well-known/oauth-authorization-server (RFC 8414). Clients that reach AuthPlane can discover all its capabilities: supported grant types, token endpoint, JWKS URI, and more.

For the resource side, your MCP server needs to expose /.well-known/oauth-protected-resource. The MCP SDKs handle this automatically when you configure the resource identifier and authorization server URL.

Why This Matters for Agents

Agents built on Claude Code, Claude Desktop, or custom orchestration frameworks can use RFC 9728 to connect to MCP servers they have never seen before. The agent fetches the discovery document, finds the authorization server URL, initiates OAuth 2.1, and gets a token scoped to exactly the tools it requested. No configuration files. No hardcoded endpoints. RFC 9728 is the first step in that fully automatic flow.