OAuth endpoint construction drops subpaths, breaking RFC 8414 compliance

[arjunkmrm]

Issue Title: OAuth endpoint construction drops subpaths, breaking RFC 8414 compliance

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.102.3
• OS Version: macOS Sequoia 15.5

Steps to Reproduce:

1. Use an OAuth server hosted at a subpath (e.g., https://server.smithery.ai/@upstash/context7-mcp/mcp)
2. Call getDefaultMetadataForUrl() from src/vs/base/common/oauth.ts
3. Observe that generated endpoints drop the subpath

Impact:

• Breaks OAuth authentication for MCP servers hosted at subpaths like https://server.smithery.ai/@upstash/context7-mcp/mcp
• Violates RFC 8414 Section 3 which requires preserving paths "between the host component and the path component, if any"
• Same issue was fixed in modelcontextprotocol/typescript-sdk#687

Reference:
RFC 8414 Section 3

[vs-code-engineering]

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.102.3. Please try upgrading to the latest version and checking whether this issue remains.

Happy Coding!

[TylerLeonhardt]

When I add that server, I get this:

Error: Protected Resource Metadata resource "https://server.smithery.ai/@upstash/context7-mcp/mcp" does not match MCP server resolved resource "https://server.smithery.ai/@upstash/context7-mcp". The MCP server must follow OAuth spec https://datatracker.ietf.org/doc/html/rfc9728#PRConfigurationValidation

[TylerLeonhardt]

If you go here:

https://server.smithery.ai/.well-known/oauth-protected-resource/@upstash/context7-mcp

You'll see that:

"resource":"https://server.smithery.ai/@upstash/context7-mcp/mcp"

Either the resource in the WWW-Authenticate header is wrong, or the resource at ^^^ that url is wrong. They have to match.

I don't think you're hitting the getDefaultMetadataForUrl

[arjunkmrm]

@TylerLeonhardt, per RFC 9728:
If the protected resource metadata was retrieved from a URL returned by the protected resource via the WWW-Authenticate resource_metadata parameter, then the resource value returned MUST be identical to the URL that the client used to make the request to the resource server. If these values are not identical, the data contained in the response MUST NOT be used.

• when you hit initial URL: https://server.smithery.ai/@upstash/context7-mcp/mcp you get a 401 with WWW-Authenticate URL: https://server.smithery.ai/.well-known/oauth-protected-resource/@upstash/context7-mcp
• then, when you hit this URL, you get the protected resource metadata:

{
    "authorization_servers": [
        "https://server.smithery.ai/@upstash/context7-mcp/"
    ],
    "resource": "https://server.smithery.ai/@upstash/context7-mcp/mcp"
}

• In this case, the resource value returned in the metadata is the same as the URL used to make the initial request: https://server.smithery.ai/@upstash/context7-mcp/mcp

Shouldn't this be correct per RFC 9728? I'm not exactly sure if it's related to getDefaultMetadataForUrl(), but it could be potentially caused by misinterpreting protected resource URL due to the dropping of subpaths. We found a similar issue with https://github.com/modelcontextprotocol/typescript-sdk/pull/687/files#diff-ac04c4c9810612210b0ac8fbf59911c8a9b826954a38eb7a0aeb26bbf73a5325

[calclavia]

If you go here:

https://server.smithery.ai/.well-known/oauth-protected-resource/@upstash/context7-mcp

You'll see that:

"resource":"https://server.smithery.ai/@upstash/context7-mcp/mcp"

Either the resource in the WWW-Authenticate header is wrong, or the resource at ^^^ that url is wrong. They have to match.

I don't think you're hitting the getDefaultMetadataForUrl

OK we just fixed this on our end. The resource should now match the URL.

[TylerLeonhardt]

With the issue closed, I'm guessing you all are good now and don't need the PR you opened?

I need to go get some clarity on RFC 9728 just to double check... I believe I've interpreted it correctly: The URL in the WWW-Authenticate after removing the Well-Known part MUST match the resource in the PRM.

That code path you originally mentioned actually from a previous spec, one where the auth server was bundled with mcp server. The spec mentioned resolving from the root. I don't see that mentioned in the current spec anymore...

[calclavia]

With the issue closed, I'm guessing you all are good now and don't need the PR you opened?

I need to go get some clarity on RFC 9728 just to double check... I believe I've interpreted it correctly: The URL in the WWW-Authenticate after removing the Well-Known part MUST match the resource in the PRM.

That code path you originally mentioned actually from a previous spec, one where the auth server was bundled with mcp server. The spec mentioned resolving from the root. I don't see that mentioned in the current spec anymore...

Yep - MCPs on Smithery seem to be working with VSCode after we fixed that on our end. We're all good now.