IETF · June 2018
RFC 8414
M. Jones, N. Sakimura, J. Bradley
Agents discover tools at runtime. Hardcoded token endpoints will not survive first contact with a new MCP server or a multi-tenant AS.
At a glance
Actors
01
Clients need a machine-readable map of the authorization server: issuer, endpoints, supported grants, PKCE methods, JWKS. Agents discover tools at runtime; hardcoded token endpoints will not survive first contact with a new MCP server or a multi-tenant AS.
02
The issuer identifier in the document MUST match the identifier used to fetch it. A document that lies about issuer is an attack (mix-up). Fetch over HTTPS; do not follow to a different host blindly.
03
RFC 8414: GET {issuer}/.well-known/oauth-authorization-server (OIDC uses /.well-known/openid-configuration). Path insertion rules exist when the issuer has a path. MCP clients MUST try both RFC 8414 and OIDC discovery path variants.
04
Flow 1
Start from an issuer URL (from PRM authorization_servers, or from user input).
GET well-known metadata (8414 and/or OIDC).
Reject if issuer does not match. Cache with TTL.
Use endpoints and capability flags (PKCE S256, PAR, DPoP, CIMD) from the document.
05
Discovery. Enables both OIDC-style identity and OAuth authorization without hardcoded URLs.
06
PRM lists authorization_servers; then you fetch 8414.
Parallel document at openid-configuration. MCP requires supporting both.
Clients MUST support both discovery mechanisms.
AS advertises CIMD support in metadata.
07
Always compare exactly. Trailing slashes matter.
SSRF and mix-up. Allow-list when you can; always use HTTPS.
08
RFC 8414, June 2018. Stable. https://www.rfc-editor.org/rfc/rfc8414.html
MCP clients MUST try both RFC 8414 and OIDC discovery path variants. Reject documents whose issuer does not match the fetched URL.