VSCode support for OAuth in MCP connections is not correct

[DinoChiesa]

Summary

Details

I have seen #269593 and #255465. I can't really tell what the resolution was for those; the tickets just seemed to get closed after some discussion without an explanation for what the plan was. Regardless, I am testing on the current VSCode and I still see some problems.

1. VSCode does not use the RFC8414-prescribed https://myhost/.well-known/oauth-protected-resource/path/to/mcp in order to ascertain the Authorization servers for the MCP server at https://myhost/path/to/mcp . It should. That is the prescribed way to discover the issuer endpoints for authorization and token redemption.

   Let's consider the example of https://api.githubcopilot.com/mcp . Per the 06-18 MCP spec, for the MCP server at https://api.githubcopilot.com/mcp, the client should

   • perform a GET https://api.githubcopilot.com/.well-known/oauth-protected-resource/mcp to understand what authorization server to use.
   • The result of that shows

     {
      "resource_name": "GitHub MCP Server",
      "resource": "https://api.githubcopilot.com/mcp",
      "authorization_servers": ["https://github.com/login/oauth"],
      "bearer_methods_supported": ["header"],
      "scopes_supported": [
        "gist",
        "notifications",
        ...
     

   • The client should then construct a URL for the oauth-authorization-server by taking the authorization_server entry (https://github.com/login/oauth) and interjecting a .well-known/oauth-authorization-server in the left-most path position, resulting in https://github.com/.well-known/oauth-authorization-server/login/oauth.
   • The client should GET that URL. In the Github case it returns:

     {
       "issuer": "https://github.com/login/oauth",
       "authorization_endpoint": "https://github.com/login/oauth/authorize",
       "token_endpoint": "https://github.com/login/oauth/access_token",
       "response_types_supported": ["code"],
       "grant_types_supported": ["authorization_code"],
       "service_documentation": "https://docs.github.com/apps/creating-github-apps/registering-a-github-app/registering-a-github-app",
       "code_challenge_methods_supported": ["S256"]
     }
     

   • The client should then build the /authorize URL starting from the authorize_endpoint shown there.

   INSTEAD of following that path, Vscode appears to perform a GET on https://myhost/.well-known/oauth-authorization-server This seems wrong . (BTW, In the case of Github MCP Server, that URL (https://api.githubcopilot.com/.well-known/oauth-authorization-server) returns 404, as I think it should. ) VSCode may be doing this to accommodate backwards-compatibility with an old, poorly conceived version of the MCP spec. But in my experience when that URL returns 404, VSCode does not then try https://myhost/.well-known/oauth-protected-resource/path/to/mcp . I have never been able to get VSCode to use that URL.

   In fact the order of preference should be the other way. It should use the oauth-protected-resource URL FIRST, and then fallback to the URL for the old, ill-designed pattern (pre 06-18). It makes no sense for the MCP Server to know all the things that are supposed to be in the oauth-authorization-server metadata. That information is owned by and managed by the Authorization server. The best the MCP Server will know is what the issuer is. That's what it returns in the oauth-protected-resource response.

2. When connecting to an MCP Server that requires OAuth, there is no way for a configuration to specify an audience for the token. When that happens, some Identity Providers do not issue appropriate tokens.

3. If I set up an MCP server and then manually copy/paste in the client ID and Secret when prompted, that client ID +secret pair seems to be re-used for every MCP server. If I change the configuration for global MCP Servers and provide a new name, but keep the same MCP URL endpoint, the old client ID and Secret is used, and it's not possible for me to update them or tell VSCode to forget them. It seems to me the cache should be (a) accessible so that I can clear it, and (b) keyed on the MCP Server NAME in the MCP.json file, and not on the URL, as I imagine it is.

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

• VS Code Version:

  Version: 1.105.0
  Commit: 03c265b1adee71ac88f833e065f7bb956b60550a
  Date: 2025-10-08T14:09:35.891Z
  Electron: 37.6.0
  ElectronBuildId: 12502201
  Chromium: 138.0.7204.251
  Node.js: 22.19.0
  V8: 13.8.258.32-electron.0
  OS: Linux x64 6.12.35-amd64
  

Steps to Reproduce:

1. connect up to Github MCP server
2. observe that the Discovery does not work.

[TylerLeonhardt]

Dino Chiesa (@DinoChiesa) can you please break this up into multiple issues so that we can tackle them one-by-one. Each may have different resolutions.

We do follow RFC8414. We do the well-known path resolution at the resource level and the auth server level.

I'd need to know more about how your auth server is configured.

I can connect fine to GitHub MCP Server, and that one is "special" because we ship a GH client id in VS Code so that doesn't do DCR or anything like that.

Having a simple MCP Server config would be helpful to debug. Doubly so if you provide a simple MCP Server that demonstrates using like, this TS SDK Example

[DinoChiesa]

My mistake; I had an incorrectly configured MCP server that was pointing to the wrong URL in the WWW-Authenticate header.

[sonrai-bradpe]

Dino Chiesa (@DinoChiesa) I'm facing a similar issue, can you tell me what you ended up using for your WWW-Authenticate header that resolved this?

[DinoChiesa]

I had an incorrect URL in the header. There were two things I changed, not sure if both were needed. 1st, it was a relative path; I changed it to an absolute path. 2nd; the path was not correct anyway.