Repository navigation
[Client] Implement Authorization Server Metadata discovery (RFC 8414) #318
Description
Context
Once the AS issuer is known (from PRM), the client must fetch its metadata at /.well-known/oauth-authorization-server (RFC 8414) to learn the authorization_endpoint, token_endpoint, registration_endpoint, scopes_supported, token_endpoint_auth_methods_supported, and grant_types_supported.
Scope
Mcp\Client\Auth\AuthorizationServerMetadataDiscoverer.- Cache resolved metadata per issuer (TTL via PSR-16 if
TokenStorageis backed by it). - Fall back to OpenID Connect discovery (
/.well-known/openid-configuration) when RFC 8414 endpoint 404s.
Conformance scenarios unblocked
auth/metadata-* (full set), auth/scope-from-scopes-supported.
Dependencies
Blocked by: #317 (PRM provides the issuer URL).
Acceptance
- Unit tests covering RFC 8414 + OIDC fallback.
- Reuses existing
Mcp\Server\Transport\Http\OAuth\OidcDiscoveryfor shape parity if practical.
cc @soyuka
Activity
chr-hertel commentedon May 26, 2026
Cross-reference: this work fully covers SEP-2351 for the MCP Spec 2026-07-28 release — the spec clarifies that MCP uses the default RFC 8414
oauth-authorization-serverwell-known suffix with path-insertion semantics (not naive append) for issuers with path components.Please ensure the implementation follows RFC 8414 §3.1 path-insertion. See umbrella #338.
[Client] Add OAuth authorization to the HTTP transport
[Client] Add OAuth authorization to the HTTP transport