Metadata discovery - handling `openid-configuration` not just `oauth-authorization-server`

[peterbud]

Describe the bug
The Model Context Protocol (MCP) Inspector, when performing Authorization Server (AS) metadata discovery via the authorization_servers field in Protected Resource Metadata (PRM) (RFC 9728), currently only attempts to fetch metadata from the /.well-known/oauth-authorization-server endpoint. Many common Authorization Servers, including Azure Active Directory, primarily expose their metadata via the /.well-known/openid-configuration endpoint, as defined by OpenID Connect Discovery. This prevents the inspector from successfully discovering AS metadata for such providers, leading to incomplete authorization flow setup.

To Reproduce
Steps to reproduce the behavior:

1. Set up a Protected Resource (your resource server) to expose its metadata at /.well-known/oauth-protected-resource (RFC 9728).
2. In this Protected Resource Metadata, include an authorization_servers entry where the issuer identifier points to an OpenID Connect-compliant Authorization Server that uses /.well-known/openid-configuration (e.g., an Azure AD tenant issuer URL like https://login.microsoftonline.com/{tenant-id}/v2.0).
3. Use the modelcontextprotocol/inspector to analyze this Protected Resource by Guided Auth flow / Metadata discovery
4. Observe the inspector's attempt to discover the Authorization Server metadata.

Expected behavior
The modelcontextprotocol/inspector should successfully discover the Authorization Server metadata by attempting to fetch from both /.well-known/oauth-authorization-server and /.well-known/openid-configuration when processing an issuer identifier from the authorization_servers array in Protected Resource Metadata. Upon successful discovery, it should report the AS's capabilities and endpoints.

Additional context
The OAuth 2.0 Authorization Server Metadata (RFC 8414) and OpenID Connect Discovery (OpenID.Discovery) specifications both define mechanisms for Authorization Server metadata publication. OpenID Connect Discovery is effectively an extension of the OAuth 2.0 metadata, and many identity providers opt to expose a single metadata document at the /.well-known/openid-configuration endpoint that satisfies both specifications. To ensure full compatibility and successful discovery across a wide range of OAuth/OIDC providers, the modelcontextprotocol/inspector should explicitly check for /.well-known/openid-configuration as a valid discovery endpoint for authorization server metadata.

[mariuszluciow]

Related: https://github.com/orgs/modelcontextprotocol/discussions/469