OAuth Metadata Discovery Should Respect Provided Authorization Server URL Before Applying RFC 8414 Path Construction

Description

The current OAuth metadata discovery implementation in src/client/auth.ts automatically applies RFC 8414 path-aware discovery patterns to authorization server URLs without first attempting to use the exact URL provided in the metadata. This causes failures when working with authorization servers like Keycloak that don't fully comply with RFC 8414 path construction but provide working endpoints.

Expected Behavior

When an authorization server URL is provided in the resource metadata (e.g., authorization_servers: ['http://localhost:9090/realms/mcp']), the SDK should:

1. First attempt discovery at the exact provided URL + /.well-known/oauth-authorization-server
2. Only if that fails, then attempt RFC 8414 path-aware discovery patterns
3. Finally fall back to root discovery as currently implemented

Current Behavior

The SDK immediately applies RFC 8414 path-aware discovery, constructing URLs like:

http://localhost:9090/.well-known/oauth-authorization-server/realms/mcp

This fails with Keycloak and other authorization servers that don't implement RFC 8414 path-aware discovery but do provide working endpoints at the standard location.

Reproduction Steps

1. Set up an authorization server that provides metadata with authorization_servers: ['http://example.com/realms/test']
2. Ensure the server has a working endpoint at http://example.com/realms/test/.well-known/oauth-authorization-server
3. Run OAuth discovery with the TypeScript SDK
4. Observe that it tries http://example.com/.well-known/oauth-authorization-server/realms/test (404) instead of the working endpoint

Environment

• @modelcontextprotocol/sdk version: 1.15.0
• Authorization Server: Keycloak (known issue with RFC 8414 compliance: Compliant with RFC8414, return server metadata at /.well-known/oauth-authorization-server/realms/{realm} keycloak/keycloak#40923)

Relevant Code

The issue appears to be in discoverOAuthMetadata() function in src/client/auth.ts around lines 370-390, where path-aware discovery is attempted first without trying the direct URL.

Proposed Solution

Modify the discovery order in discoverOAuthMetadata() to:

1. Try direct URL: ${authorizationServerUrl}
2. Try path-aware (current first attempt): ${origin}/.well-known/oauth-authorization-server${pathname}
3. Try root fallback (current second attempt): ${origin}/.well-known/oauth-authorization-server

This would maintain RFC 8414 compliance while being more practical for real-world authorization servers.

Additional Context

This issue affects interoperability with common authorization servers like Keycloak that provide functional OAuth metadata endpoints but don't implement the full RFC 8414 specification. The current implementation prioritizes strict RFC compliance over practical functionality.

Related Issues

This issue is related to but distinct from #616, which addresses falling back to .well-known/openid-configuration when .well-known/oauth-authorization-server fails entirely (e.g., with Google's authorization server).

The issues are complementary:

• Issue OAuth metadata discovery: fall back to openid-configuration #616: Handles cases where authorization servers don't provide oauth-authorization-server endpoints at all
• This issue: Handles cases where authorization servers provide oauth-authorization-server endpoints but not at RFC 8414 path-aware locations

Both issues aim to improve compatibility with real-world authorization server implementations that don't fully conform to RFC 8414.

Note: I've searched existing issues and found the related issue #616 mentioned above. This follows the project's contributing guidelines for providing clear reproduction steps and context.