---
type: "post"
id: "protected-resource-metadata-oauth-2-0-4bbb5a"
slug: "protected-resource-metadata-oauth-2-0-4bbb5a"
title: "Protected Resource Metadata — OAuth 2.0"
description: "RFC 9728 standardizes a JSON metadata document that an OAuth-protected API can publish so clients can discover trusted authorization servers, scopes, and token presentation requirements."
retrieval_nugget: "RFC 9728 standardizes a JSON metadata document that an OAuth-protected API can publish so clients can discover trusted authorization servers, scopes, and token presentation requirements. Because the Model Context Protocol requires this mechanism, MCP clients have a defined path from an API URL to OAuth configuration instead of relying on preconfigured server details."
published_at: "2026-11-11"
updated_at: "2026-11-11"
record_date: "2026-11-11"
date_kind: "published_at"
topics: ["api-design","security"]
entities: ["OAuth 2.0 Protected Resource Metadata","Model Context Protocol"]
related_patterns: ["agent-protocols-become-interoperability-layer"]
novelty_label: "new_fact"
what_changed: "RFC 9728 standardizes API metadata discovery, including trusted authorization servers, scopes and token presentation; the Model Context Protocol requires it."
prior_refs: ["https://newruntime.com/posts/announcing-dpop-support-for-google-oauth-securing-refresh-0a4963/"]
source_url: "https://oauth.net/2/protected-resource-metadata"
source_urls: ["https://oauth.net/2/protected-resource-metadata"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:protected-resource-metadata-oauth-2-0-4bbb5a"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/protected-resource-metadata-oauth-2-0-4bbb5a/","markdown":"https://newruntime.com/posts/protected-resource-metadata-oauth-2-0-4bbb5a.md","json":"https://newruntime.com/posts/protected-resource-metadata-oauth-2-0-4bbb5a.json"}
markdown_url: "https://newruntime.com/posts/protected-resource-metadata-oauth-2-0-4bbb5a.md"
---

# Protected Resource Metadata — OAuth 2.0

## Retrieval answer

RFC 9728 standardizes a JSON metadata document that an OAuth-protected API can publish so clients can discover trusted authorization servers, scopes, and token presentation requirements. Because the Model Context Protocol requires this mechanism, MCP clients have a defined path from an API URL to OAuth configuration instead of relying on preconfigured server details.

## Summary
RFC 9728 standardizes a JSON metadata document that an OAuth-protected API can publish so clients can discover trusted authorization servers, scopes, and token presentation requirements. Because the Model Context Protocol requires this mechanism, MCP clients have a defined path from an API URL to OAuth configuration instead of relying on preconfigured server details.

## What happened
OAuth.net describes Protected Resource Metadata as a standard JSON document that an API publishes for OAuth clients. RFC 9728 is published at rfc-editor.org. The document tells a client which authorization servers the protected resource accepts tokens from, which scopes it uses, and how a token should be presented. OAuth.net says this is useful when client software must work with independently deployed resource servers, or when one API can be paired with different authorization servers.

The metadata document is served from a well-known URL derived from the resource identifier: `/.well-known/oauth-protected-resource`. If the resource identifier includes a path, the well-known segment is placed between the host and that path. The only required field is `resource`, and it must match the resource identifier that the client used to construct the metadata URL. This matching requirement makes the identifier part of the discovery and validation contract rather than a loose label.

The `authorization_servers` field lists issuers that the resource trusts. A client can then fetch each issuer's Authorization Server Metadata to locate its endpoints. Other fields may identify `scopes_supported`, `bearer_methods_supported`, a `jwks_uri`, and support for DPoP-bound or Mutual TLS-bound tokens. The resulting chain separates the resource's OAuth requirements from a client-side table of manually maintained endpoint settings.

RFC 9728 also defines a `resource_metadata` parameter for the `WWW-Authenticate` response header. When a request arrives without a valid token, a resource server can send a 401 response that points to its metadata document. The client can follow that pointer rather than guessing the metadata location. OAuth.net's example includes a resource URL, one authorization server, `profile` and `email` scopes, and `header` as a bearer-token method. OAuth.net says MCP requires Protected Resource Metadata so that an MCP client can find the appropriate authorization server for an MCP server it receives. The page describes a standard and its fields, not a new product release, hosted service, price, or deployment.

## What the archive adds
New Runtime's earlier coverage on October 21 noted that Google OAuth supports DPoP for refresh-token protection ([Announcing DPoP Support for Google OAuth: Securing Refresh Tokens](https://newruntime.com/posts/announcing-dpop-support-for-google-oauth-securing-refresh-0a4963/)). On October 22, an earlier New Runtime note examined OAuth security for browser-based apps ([OAuth 2.0 for Browser-Based Apps](https://newruntime.com/posts/oauth-2-0-for-browser-based-apps-analysis-8950b5/)). RFC 9728 is a new fact in that broader OAuth security and interoperability thread: it standardizes resource-side metadata discovery rather than changing refresh-token binding or browser-client security.

## Trend signal
This supports [agent protocols becoming the interoperability layer](https://newruntime.com/patterns/agent-protocols-become-interoperability-layer/). A standard discovery document lets clients and independently deployed services coordinate without hard-coded pairings, and MCP's requirement makes that connection direct. The RFC defines a protocol surface, however; it does not demonstrate broad adoption or prove that independently built implementations interoperate reliably.

## Why now
The timing matters because MCP requires this discovery mechanism for a client to identify the appropriate authorization server for an MCP server. That requirement makes resource metadata operationally relevant to teams connecting MCP clients to OAuth-protected services. It changes the work from documenting an OAuth setup for known integrations to supporting discovery when the client has not been configured for that particular resource in advance.

## Why it matters
OAuth discovery is often where integrations become brittle. A client may know the resource URL but not know which issuer the resource trusts, which scopes to request, or how to present the eventual token. RFC 9728 provides a standard place for resource operators to publish those details. Its 401 response pointer also lets a resource direct an unauthenticated client to that location instead of assuming that every client can derive it correctly.

For teams building MCP services, this is a compatibility concern rather than merely a documentation improvement. A client needs a consistent route from an MCP server to authorization configuration, and an implementation must carry that route through issuer metadata, endpoint selection, token acquisition, and the eventual protected request. Standardized discovery can reduce bespoke configuration and per-server assumptions. It does not remove the need to validate issuer trust, requested scopes, audience or resource binding, and token-handling behavior in each deployment.

The distinction matters for platform teams as well. Publishing metadata is an interface commitment: changing the resource identifier, trusted issuer list, or accepted bearer method can affect clients that rely on automated discovery. Treat the document as a versioned part of the authentication boundary, with tests for both direct discovery and the unauthenticated 401 path.

## Limits and uncertainty
OAuth.net explains the standard's fields and discovery flow, but it does not establish how widely RFC 9728 is deployed or how consistently implementations handle path-based resource identifiers and 401 challenges. It also does not report cross-client interoperability results. RFC 9728 specifies metadata and discovery, not a complete authorization implementation: operators still need correctly configured authorization servers, secure token validation, and appropriate issuer and audience checks. The page does not quantify integration savings, latency effects, or operational failure rates. MCP's requirement identifies a compatibility expectation, but the page does not enumerate which MCP clients or servers currently meet it.

## Skill to build now
If you operate an OAuth-protected MCP server, test discovery from a clean client that knows only the resource URL. Confirm that the well-known document's `resource` exactly matches the identifier used in the request, that `authorization_servers` names the intended issuer, and that issuer metadata exposes usable endpoints. Then make an unauthenticated request and verify that the 401 `WWW-Authenticate` challenge points to the same metadata document. Repeat the test for any path-based resource identifier; the placement of the well-known segment differs from a host-only resource URL.

## Reader takeaway
RFC 9728 makes OAuth resource discovery explicit: publish metadata at the well-known URL, identify trusted authorization servers, and let clients follow the chain to token endpoints. For MCP builders, it is a compatibility requirement worth testing end to end, not an optional documentation improvement.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Api Design](https://newruntime.com/topics/api-design.md): Explore the api-design topic hub.
- topic hub: [Security](https://newruntime.com/topics/security.md): Explore the security topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)