Identity for AI

Protected Resource Metadata in the AuthPlayground

Helping AI clients discover how to get authorized.

Sarah asks the AI assistant to prepare her for a meeting with Apex Logistics. The AI assistant discovers an MCP server or API it needs to call, but doesn’t know how these resources are protected or which authorization server to use.

OAuth 2.0 Protected Resource Metadata (RFC 9728) provides a standard way for clients to discover authorization information for protected resources.

The protected resource metadata model

This protocol enables a client to discover information about a protected resource, including which authorization server protects it. The flow looks like this:

  1. An AI or MCP client calls the protected resource.

  2. The protected resource returns a 401 with resource_metadata that identifies the authorization server.

  3. The client uses the metadata for OAuth authorization.

The resource tells the client that it requires authorization and provides the metadata needed to discover how it’s protected.

The AuthPlayground implementation

Entities involved: Client application, authorization server B, resource server

The AuthPlayground demonstrates the Protected Resource Metadata flow in three steps:

  1. Call the protected resource.

  2. Fetch protected resource metadata.

  3. Fetch authorization server metadata.

Step 1: Call the protected resource

The client calls the resource without an access token:

GET /rs/api/data

The error response indicates that the resource is protected and provides a link to the metadata:

401 Unauthorized

WWW-Authenticate: Bearer
  resource_metadata=".../.well-known/oauth-protected-resource/rs"

This link tells the client where to retrieve metadata about the protected resource.

Step 2: Fetch protected resource metadata

The client retrieves the metadata:

GET /.well-known/oauth-protected-resource/rs

The metadata identifies the authorization server and describes capabilities such as scopes and DPoP support:

{
  "resource": "https://.../rs",
  "authorization_servers": [
    "https://.../idp"
  ],
  "scopes_supported": [
    "openid",
    "profile",
    "email",
    "read",
    "write"
  ],
  "dpop_signing_alg_values_supported": [
    "RS256",
    "ES256"
  ]
}

Step 3: Fetch authorization server metadata

The client retrieves metadata from the advertised authorization server:

GET /.well-known/oauth-authorization-server/idp

The response includes capabilities such as the authorization endpoint, token endpoint, PAR, PKCE, and other supported OAuth features. The client can use this information for authorization.

How Protected Resource Metadata relates to other concepts

A supporting protocol for dynamic AI

Sarah’s AI assistant discovers an MCP server it needs for the Apex Logistics workflow. In dynamic AI and MCP environments, clients might not have every resource and authorization configuration hard coded ahead of time. Protected resource metadata doesn’t identify the agent, authorize Sarah, establish delegation, or determine what the AI can do. Its job is to help the client discover how a protected resource expects access to be authorized.

How it differs from CIMD

Protected Resource Metadata and Client ID Metadata Documents (CIMD) solve opposite sides of the discovery problem. CIMD helps an authorization server discover metadata about the client. Protected resource metadata helps a client discover which authorization server protects the resource and how to reach it.

Neither protocol grants access or establishes trust by itself. Discovery provides information that must be validated and evaluated under the appropriate security policy.

Key takeaways

Protected Resource Metadata isn’t an AI-specific identity protocol. It’s standard OAuth infrastructure that’s useful when AI applications and MCP clients interact with resources dynamically. It contributes to the Identity for AI story by enabling an AI client to discover not only a resource, but also the authorization infrastructure required to access it.