Description
Describe the bug
According to the OAuth 2.0 Authorization Server Metadata spec, if the oauth url contains a path, e.g. "https://my.auth-server.com/oauth/", then the well-known endpoint should be constructed by inserting the well-known suffix between the host and path, i.e. https://my.auth-server.com/.well-known/oauth-authorization-server/oauth
See here
The current implementation strips the path
Why this is important
Due to Dynamic Client Registration, multitenant auth servers (i.e. auth servers with multiple clients) may choose to encode a tenant id in the auth server path, ensuring that all clients registered through the registration endpoint are registered against that tenant.
For example:
- MCP server has tenant id xyz with my.auth-server.com.
- MCP server includes that tenant id in its oauth-protected-resource auth server: https://my.auth-server.com/tenant/xyz
- Client looks up the metadata for the auth server https://my.auth-server.com/.well-known/oauth-authorization-server/tenant/xyz (this is where the bug is)
- Auth server generates tenant-specific configuration metadata, in particular with the registration endpoint
https://my.auth-server.com/tenant/xyz/reg
- Client registers a client using DCR at that endpoint
- Auth server verifies that xyz is a registered tenant, and issues an access token specifically for that tenant.
To Reproduce
Steps to reproduce the behavior:
- Create an MCP server, with oauth-protected-resource pointing to e.g. https://my.auth-server.com/oauth
- Test that server using the inspector.
- Note, the inspector strips the path.

Expected behavior
The path should be included as per the spec