Resolving Authorization server metadata URL omits the base path of the Authorization server URL

[pavinduLakshan]

Describe the bug

When the third party authorization server URL is not an origin, the oauth authorization server metadata URL is resolved to the origin of the passed url.

This is due to the prefixed / in the relative URL path in

typescript-sdk/src/client/auth.ts

Line 272 in 0516f98

const url = new URL("/.well-known/oauth-authorization-server", authorizationServerUrl);

Refactoring the above to something like const url = new URL(authorizationServerUrl + ".well-known/oauth-authorization-server"); will fix this.

To Reproduce

1. Configure an authorization server path with a base path in MCP server's protected resource metadata. (eg: https://api.asgardeo.io/t/pavinduorg)

2. Observe that the oauth authorization server metadata URL is resolved to https://api.asgardeo.io/.well-known/oauth-authorization-server instead of https://api.asgardeo.io/t/pavinduorg/.well-known/oauth-authorization-server

Expected behavior

Authz metadata url construction should not omit the basepath of authorization server URL.

Logs
N/A

Additional context
N/A

[KKonstantinov]

Hello,

The implementation of the SDK seems as per the 2025-03-26 MCP spec, see Authorization Base URL, which states .well-known must always be at the domain root.

[pavinduLakshan]

Hello,

The implementation of the SDK seems as per the 2025-03-26 MCP spec, see Authorization Base URL, which states .well-known must always be at the domain root.

Hi @KKonstantinov, the SDK does implement the latest draft, as OAuth protected resource metadata discovery is now supported[1]. However, as you pointed out, the 03-26 version still uses the domain root, and it seems the URL construction logic hasn’t yet been updated to fully align with the draft.

[1]

typescript-sdk/src/client/auth.ts

Line 222 in d5c996b

export async function discoverOAuthProtectedResourceMetadata(

[allenzhou101]

This is definitely an issue with regards to the draft auth spec that support Protected Resource Metadata (PRM). Core issue is the URL construction here:

typescript-sdk/src/client/auth.ts

Line 272 in 590d484

const url = new URL("/.well-known/oauth-authorization-server", authorizationServerUrl);

With the 2025-03-26 MCP spec the code makes sense since the metadata needs to be discovered from the root path, however with the new spec you can support more robust path mechanisms by simply including the issuer of the Authorization Server in the PRM.

As a workaround, we are hosting the Authorization Server Metadata (ASM) at a root path-based issuer and pointing at the content of the real ASM.

[selcuktemizsoy]

@allenzhou101 are we planning to fix it here? We use keycloak and we can't host it under root host. it comes after the realms.

[tbulgerin]

Configure an authorization server path with a base path in MCP server's protected resource metadata. (eg: https://api.asgardeo.io/t/pavinduorg)

Observe that the oauth authorization server metadata URL is resolved to https://api.asgardeo.io/.well-known/oauth-authorization-server instead of https://api.asgardeo.io/t/pavinduorg/.well-known/oauth-authorization-server

I think this should actually be https://api.asgardeo.io/.well-known/oauth-authorization-server/t/pavinduorg as per RFC 8414:

The client would make the following request when the issuer
identifier is "https://example.com" and the well-known URI suffix is
"oauth-authorization-server" to obtain the metadata, since the issuer
identifier contains no path component:

 GET /.well-known/oauth-authorization-server HTTP/1.1
 Host: example.com

If the issuer identifier value contains a path component, any
terminating "/" MUST be removed before inserting "/.well-known/" and
the well-known URI suffix between the host component and the path
component. The client would make the following request when the
issuer identifier is "https://example.com/issuer1" and the well-known
URI suffix is "oauth-authorization-server" to obtain the metadata,
since the issuer identifier contains a path component:

 GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
 Host: example.com

[antoniocasagrande-airia]

Same issue here, Keycloak is widely used, please consider this issue.

[pavinduLakshan]

Configure an authorization server path with a base path in MCP server's protected resource metadata. (eg: api.asgardeo.io/t/pavinduorg)
Observe that the oauth authorization server metadata URL is resolved to api.asgardeo.io/.well-known/oauth-authorization-server instead of api.asgardeo.io/t/pavinduorg/.well-known/oauth-authorization-server

I think this should actually be api.asgardeo.io/.well-known/oauth-authorization-server/t/pavinduorg as per RFC 8414:

The client would make the following request when the issuer
identifier is "example.com" and the well-known URI suffix is
"oauth-authorization-server" to obtain the metadata, since the issuer
identifier contains no path component:

 GET /.well-known/oauth-authorization-server HTTP/1.1
 Host: example.com

If the issuer identifier value contains a path component, any
terminating "/" MUST be removed before inserting "/.well-known/" and
the well-known URI suffix between the host component and the path
component. The client would make the following request when the
issuer identifier is "example.com/issuer1" and the well-known
URI suffix is "oauth-authorization-server" to obtain the metadata,
since the issuer identifier contains a path component:

 GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
 Host: example.com

Hi @tbulgerin thanks for pointing that out. However, even if we use api.asgardeo.io/.well-known/oauth-authorization-server/t/pavinduorg as the metadata URL, current SDK implementation would omit the tenant path.

[tbulgerin]

Hi @tbulgerin thanks for pointing that out. However, even if we use api.asgardeo.io/.well-known/oauth-authorization-server/t/pavinduorg as the metadata URL, current SDK implementation would omit the tenant path.

Agreed, the current SDK implementation doesn't handle path components of the issuer identifier properly when constructing the .well-known endpoint, so I think the bug is valid. I was just pointing out that as per the specification, the path component should be after the .well-known and well-known URI suffix, and not before it, in case anyone picked up this bug to fix it.

[thecopy]

A significant number of real-world AS are incompatible with the current implementation of this SDK. KeyCloak, Okta custom authorization server, and Azure Entra to name a few. I understand the desire to stick to specifications, but the real-world is messy.

IMO rather than expecting companies/organizations to make breaking changes to their existing authentication infrastructure, this SDK should adapt to the messy reality.

Just my $ 0.02