OAuth metadata discovery: fall back to openid-configuration

[david-hamilton-glean]

Is your feature request related to a problem? Please describe.

Connecting an MCP client to an MCP server whose authorization server is Google fails OAuth metadata discovery. This is because Google's authorization server metadata is at https://accounts.google.com/.well-known/openid-configuration as per the Google Identity docs. The authorization server https://accounts.google.com does not respond to https://accounts.google.com/.well-known/oauth-authorization-server

curl https://my-mcp-server/.well-known/oauth-protected-resource (truncated)

{
  "authorization_servers": [
      "https://accounts.google.com"
  ]
}

curl https://accounts.google.com/.well-known/openid-configuration (truncated)

{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
  "token_endpoint": "https://oauth2.googleapis.com/token",
  "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
  "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs"
}

Describe the solution you'd like

The most straightforward thing to do is to fall back to /.well-known/openid-configuration for authorization servers that do not respond to /.well-known/oauth-authorization-server. However this presumably requires a spec change.

Describe alternatives you've considered

Another possibility is to allow OAuthClientProvider to provide the OAuth metadata and to start discovery only when the metadata isn't present. This would be a general purpose escape valve for misconfigured or misbehaving authorization servers that may be outside the control of the MCP server maintainers.

A further possibility is to allow OAuthClientProvider to provide only the URL where OAuth authorization server metadata should be searched for during discovery.

Additional context

[david-hamilton-glean]

Upon re-reading rfc8414§3 it seems valid for OAuth authorization servers to provide metadata at "openid-configuration".

Some OAuth applications will choose to use the well-known URI suffix "openid-configuration". As described in Section 5, despite the identifier "/.well-known/openid-configuration", appearing to be OpenID specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect.

So this might be more of a bug fix rather than an enhancement.

an OAuth 2.0 application using this specification MUST specify what well-known URI suffix it will use for this purpose. [snip]

Section 3 is somewhat vague on how the well-known URI suffix is to be communicated, but either way it seems the SDK should either fall back to openid-configuration or allow the URL to be specified.