Is your feature request related to a problem? Please describe.
Many authorization servers haven't implement the pure OAuth RFC 8414 metadata endpoint at /.well-known/oauth-authorization-server. As a result, MCP clients can’t perform automatic discovery and must be manually configured, which undermines the plug-and-play goal of the spec.
Describe the solution you'd like
When RFC 8414 discovery at /.well-known/oauth-authorization-server returns 404, fall back to OpenID Connect discovery at /.well-known/openid-configuration, map its fields into our OAuthMetadata shape, and proceed normally.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
In the latest MCP draft (see “Protected-Resource Metadata” flow in the Basic Authorization spec, a client first fetches the resource‐metadata from /.well-known/oauth-protected-resource to learn the authorization_servers, resource, and scopes_supported. It then uses that information to drive its subsequent discovery and token request steps. This RFC 9728 style metadata flow makes it even more important to gracefully fall back from pure OAuth discovery to OpenID Connect discovery when /.well-known/oauth-authorization-server isn’t available.
Is your feature request related to a problem? Please describe.
Many authorization servers haven't implement the pure OAuth RFC 8414 metadata endpoint at /.well-known/oauth-authorization-server. As a result, MCP clients can’t perform automatic discovery and must be manually configured, which undermines the plug-and-play goal of the spec.
Describe the solution you'd like
When RFC 8414 discovery at /.well-known/oauth-authorization-server returns 404, fall back to OpenID Connect discovery at /.well-known/openid-configuration, map its fields into our OAuthMetadata shape, and proceed normally.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
In the latest MCP draft (see “Protected-Resource Metadata” flow in the Basic Authorization spec, a client first fetches the resource‐metadata from /.well-known/oauth-protected-resource to learn the authorization_servers, resource, and scopes_supported. It then uses that information to drive its subsequent discovery and token request steps. This RFC 9728 style metadata flow makes it even more important to gracefully fall back from pure OAuth discovery to OpenID Connect discovery when /.well-known/oauth-authorization-server isn’t available.