OAuth Discovery — RFC 8414 & RFC 9728

Identity & trust · IETF OAuth Working Group · Updated 2026-07-31

Status: RFC 8414: Proposed Standard, June 2018 · RFC 9728: Proposed Standard, April 2025 · Authoritative source

The two metadata files that let an agent walk from “401 Unauthorized” to a completed OAuth flow with no human in the loop — and, since the 2026-07-28 MCP spec, the mandatory front door of every authenticated MCP server.

Authorization used to require reading the docs. These two RFCs replace the docs with JSON. RFC 9728 (Protected Resource Metadata, April 2025) gives the resource server a discovery file — /.well-known/oauth-protected-resource — naming the authorization servers that protect it; a 401 response can point straight at that file via the WWW-Authenticate parameter resource_metadata. RFC 8414 (Authorization Server Metadata, June 2018) is the older sibling on the other side: /.well-known/oauth-authorization-server describes the authorization server itself — authorization and token endpoints, PKCE support, and the registration endpoint if clients may self-register. RFC 8414 generalizes OpenID Connect Discovery (2014), with one trap: for issuers with a path component, OIDC appends its well-known segment while 8414 inserts it between host and path — so clients probe multiple candidate URLs.

Chained, they make auth fully self-describing: 401 → resource metadata → authorization_servers → AS metadata → endpoints → token. Every hop is a GET to a predictable URL with a machine-readable answer, which is exactly the property an autonomous agent needs.

The MCP specification made this concrete: the current version (2026-07-28) requires MCP servers to implement RFC 9728 (“MCP servers MUST implement OAuth 2.0 Protected Resource Metadata”), requires the authorization_servers field that the RFC itself leaves optional — so the minimal compliant document is just resource plus authorization_servers — and requires authorization servers to publish RFC 8414 or OIDC Discovery metadata — clients must support both. Resource Indicators (RFC 8707) bind the issued token to the specific MCP server. On the agentic web, this pair has graduated from good practice to protocol requirement.

The discovery chain, end to end

GET /mcp            → 401 Unauthorized
                      WWW-Authenticate: Bearer resource_metadata=
                        "https://api.example.com/.well-known/oauth-protected-resource"
GET /.well-known/oauth-protected-resource
                    → { "resource": "https://api.example.com",
                        "authorization_servers": ["https://auth.example.com"],
                        "scopes_supported": ["mcp:read"] }
GET https://auth.example.com/.well-known/oauth-authorization-server
                    → { "authorization_endpoint": "...", "token_endpoint": "...",
                        "code_challenge_methods_supported": ["S256"] }

How AgentGrade checks it

Not yet scored: OAuth discovery probing (both well-known files, RFC 8414 and 9728) is specced for the scanner’s discovery sweep. Today the scanner exercises the adjacent surface — the MCP handshake itself — and credits protected MCP servers that answer with a well-formed 401 challenge. Scan your site to see where you stand.

Related

• MCP — the protocol that now mandates this
• RFC 7591 — client self-registration, the next hop
• RFC 8615 — the /.well-known/ mechanism underneath

All standards

RFC 9421 · Web Bot Auth · RFC 8615 · MCP · A2A · x402 · WebMCP · llms.txt · RFC 9309 · RFC 9110 · RFC 9116 · OAuth Discovery · RFC 7591 · RFC 9727 · ACP / UCP / AP2 · Index