fix: preserve auth server path in OAuth metadata URL construction

[dankelleher]

Previously, the path was stripped when constructing the well-known OAuth metadata URL. Per RFC 8414 §3.1, the path must be preserved after the .well-known segment to support multitenant auth servers that encode tenant IDs in the path.

Fixes issue #520

• Fix oauthAuthServerMetadataUrl to preserve path segments
• Add comprehensive test coverage for the function

Motivation and Context

The current solution brings challenges for multitenant auth servers

How Has This Been Tested?

I tested a local deployment of the inspector with this change hacked in and it solved the issue.

Breaking Changes

No

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[peterbud]

I have a question related to this: How this change would handle for example the metadata endpoints in Azure/Entra or Google?

For example for a normal Entra app has a metdata endpoint like this:
https://login.microsoftonline.com/<tenantId>/v2.0/.well-known/openid-configuration

In the .well-known/oauth-protected-resource route the returned info is something like:

{ "resource": "https://login.microsoftonline.com/<tenantId>/v2.0", "authorization_servers": [ "https://login.microsoftonline.com/<tenantId>/v2.0" ], "scopes_supported": [ "all" ], "bearer_methods_supported": [ "header", "query", "body" ], ... }

So the authorization_server DOES have a tenant and a suffix, but the metadata endpoint should NOT inject the .well-known/oauth-authorization-server or .well-known/openid-configuration before the suffix.

TBH I'm not sure what is the right solution for this.

[lbroudoux]

I'm facing the same situation as @peterbud here. I think supporting "resourceMetadataUrl in the WWW-Authenticate header when returning a 401 response to the MCP Client" (see #576) would help in our case.