OAuth 2.0 Protected Resource Metadata

OAuth 2.0 Protected Resource Metadata is the missing half of OAuth discovery. RFC 8414 told a client how to learn about an authorization server; nothing told it anything about the resource it was trying to reach — which AS protects this API, what scopes exist, whether a bearer token is even accepted. That was fine when a developer read the docs once and hardcoded it. It is not fine when the client is an agent meeting the API for the first time at runtime. Michael Jones, Phil Hunt and Aaron Parecki published it as Standards Track in April 2025.

• /.well-known/oauth-protected-resource - The registered path. One JSON document, served by the resource itself.
• resource - The only REQUIRED field: the resource identifier, which is what a client puts in the resource parameter so the AS mints a token with the right audience.
• authorization_servers - Which issuers can mint tokens for this API. This is the field that turns a 401 into a next step instead of a dead end.
• scopes_supported, bearer_methods_supported - What to ask for, and how to present it.
• dpop_bound_access_tokens_required, tls_client_certificate_bound_access_tokens - Whether bearer semantics are accepted at all, or whether the token must be bound to a key (DPoP) or a client certificate (mTLS).
• signed_metadata - The metadata itself as a signed JWT, for when the document’s integrity has to be provable rather than assumed.
• WWW-Authenticate: ... resource_metadata="..." - The challenge parameter that makes the whole thing self-bootstrapping: fail a call, get told where the instructions are.

This is the single most useful entry in the agent-authentication story for people who run APIs, because it is the only part of the IETF agent auth framework that is a file you can publish today. Everything else in that document — WIMSE identifiers, Transaction Tokens, attestation — lives inside your infrastructure and is invisible from outside. RFC 9728 is a JSON document at a fixed path, in the same family as /.well-known/agent-card.json and /.well-known/api-catalog, and it is what an agent reads to figure out how to authenticate without a human in the loop.

A warning for anyone measuring adoption, learned the hard way: do not probe this with a status code. Sampling well-known paths across known API hosts in August 2026, api.slack.com returned HTTP 200 with text/html for /.well-known/oauth-protected-resource, /.well-known/oauth-authorization-server and /.well-known/openid-configuration — a documentation-site catch-all that answers 200 to everything. Credit only a response that parses as JSON into an object carrying resource. The same soft-200 pattern inflates every well-known adoption number published without a body check.