agenticweb.wiki

OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization) /.well-known/oauth-protected-resource

By Belgravia Labs Standards Observatory · Last verified · 3 primary sources

OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization) is an agentic-web standard (well-known file — /.well-known/oauth-protected-resource) at step 3, Permit, governed by IETF OAuth Working Group; its status is "Proposed Standard and Proposed Standard". It answers: "How does an agent (or an MCP client acting for it) discover which authorization server protects a resource, and what that authorization server's endpoints and capabilities are, before requesting access?" Implementation status is multi-implementation, last verified 2026-10-24.

Permit This record covers the pairing of RFC 8414 (OAuth 2.0 Authorization Server Metadata, published June 2018) and RFC 9728 (OAuth 2.0 Protected Resource Metadata, published 2025), as they are increasingly cited together as the discovery backbone for AI agent authorization, including by the MCP authorization specification and by newer conventions such as auth.md [1][2][3]. Both are mature, Internet Standards Track IETF RFCs, not agent-specific drafts — this record exists because their combination has become a de facto permit-discovery mechanism for the agentic web, not because either RFC was written with agents specifically in mind.

Overview

RFC 8414 defines a JSON metadata document, conventionally at /.well-known/oauth-authorization-server, listing an authorization server's endpoints (authorization, token, etc.) and supported capabilities (grant types, scopes, PKCE support, and so on) so a client can configure itself without hardcoded assumptions [2]. RFC 9728, the newer companion, defines the resource-server side: a JSON document, conventionally at /.well-known/oauth-protected-resource, naming which authorization server(s) protect a given resource and what scopes it supports, closing the gap where a client encountering an unfamiliar API had no standard way to learn which authorization server to talk to [1]. Chained together — typically triggered by a 401 response whose WWW-Authenticate header names the Protected Resource Metadata URL — an agent can go from 'I got denied access to this API' to 'here is the authorization server and its capabilities' with two GET requests and no prior configuration [3].

Neither RFC defines agent identity, delegation semantics, or content-use permissions; they are pure discovery/metadata mechanisms that any OAuth 2.0 client, human-driven or agentic, can use. This is why several of the newer, more agent-specific drafts in this dataset (auth.md, and indirectly DAAP and AAP, which build on standard OAuth server metadata rather than defining their own) lean on these two RFCs as their discovery layer rather than reinventing one.

As of this verification (2026-09-06), both documents are final, numbered RFCs on the Standards Track, so phase is stable and there is no version-in-flux to track. Implementation is recorded as multi-implementation on the strength of RFC 8414's seven-plus years of adoption across the OAuth ecosystem (essentially every major identity provider implements it) and RFC 9728's growing adoption for resource servers, including its explicit use in the MCP authorization specification. What is unresolved: this record does not independently measure what fraction of AI-agent-facing APIs specifically (as opposed to OAuth generally) publish RFC 9728 metadata; that would require a dedicated probe run against a domain sample of agent-facing services.

Discovery and probe

well-known files at the resource server and the authorization server, chained by a WWW-Authenticate challenge · /.well-known/oauth-protected-resource

GET {resource_server}/.well-known/oauth-protected-resource
parse:     A JSON document per RFC 9728 with a 'resource' field and an 'authorization_servers' array; follow the first authorization_servers entry to {authorization_server}/.well-known/oauth-authorization-server per RFC 8414 to fetch endpoint and capability metadata
on absent: Resource server does not publish RFC 9728 Protected Resource Metadata; an agent must fall back to a 401 response's WWW-Authenticate header (if present) or vendor-specific documentation to find the authorization server

Live check run by the MCP probe: GET /.well-known/oauth-protected-resource. RFC 9728 protected resource metadata requires the resource field.

{
 "path": "/.well-known/oauth-protected-resource",
 "expect": {
  "json_keys": [
   "resource"
  ]
 },
 "note": "RFC 9728 protected resource metadata requires the resource field."
}

Instances

Every instance with its source is listed on the instances page.

See also

Comparisons

References

  1. RFC 9728, 'OAuth 2.0 Protected Resource Metadata,' is an Internet Standards Track document representing IETF consensus, defining a metadata format an OAuth 2.0 client or authorization server uses to learn how to interact with a protected resource. — https://www.rfc-editor.org/rfc/rfc9728.html (2025) VERIFIED
  2. RFC 8414, 'OAuth 2.0 Authorization Server Metadata,' published June 2018, is an Internet Standards Track document defining the companion metadata format for an authorization server's own endpoints and capabilities. — https://www.rfc-editor.org/rfc/rfc8414.html (2018-06) VERIFIED
  3. The auth.md specification (a distinct, single-vendor agent-registration protocol) documents both RFCs being chained together in a live agent-discovery flow: a 401's WWW-Authenticate header points to RFC 9728 Protected Resource Metadata, which points to RFC 8414 Authorization Server Metadata. — https://auth-md.com/auth.md (2026-06) REPORTED

Verification log and errata

JSON · Markdown · OKF v0.2

Frequently asked questions

What is OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)?
OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization) is an agentic-web standard (well-known file — /.well-known/oauth-protected-resource) at step 3, Permit, governed by IETF OAuth Working Group; its status is "Proposed Standard and Proposed Standard". It answers: "How does an agent (or an MCP client acting for it) discover which authorization server protects a resource, and what that authorization server's endpoints and capabilities are, before requesting access?" Implementation status is multi-implementation, last verified 2026-10-24.
What is the adoption and standardization status of OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)?
Proposed Standard (RFC 8414, published June 2018) and Proposed Standard (RFC 9728, published April 2025); both are products of IETF consensus, not works in progress, governed by IETF OAuth Working Group; both are Internet Standards Track RFCs with IETF/IESG consensus. Implementation: multi-implementation. Version: RFC 8414 (2018-06) and RFC 9728 (2025-04) (2025-04). Last verified 2026-10-24.
How does OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization) compare to other permit protocols?
OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization) is one of 32 standards at step 3, Permit (What may the agent do here?). It pairs with Model Context Protocol, auth.md, AI Agent Authentication and Authorization, Identity Assertion JWT Authorization Grant (ID-JAG). Head-to-head comparisons on this site: OAuth 2.0 Consent & DCR vs CIMD & Agent OAuth Metadata, auth.md, OAuth Client ID Metadata Document. Every standard at this step is listed at https://agenticweb.wiki/category/permit/.