microsoft
MCP Auth Scope Selection
I would like to request a feature that supports selecting a subset of scopes when attempting to connect to a remote MCP server that requires authentication. Currently, VS Code requests all scopes by default, which can cause issues with Conditional Access (CA) policies blocking token requests for certain resources. By allowing users to select specific scopes, we can avoid these issues and ensure smoother integration with apis protected by conditional access.
Currently we take the scopes supported in the PRM: https://github.com/microsoft/vscode/blob/cbf19a68dcdf11231855adc915b6d319e7f26326/src/vs/workbench/api/common/extHostMcp.ts#L328-L336 and fallback to what the server has... and then fallback to no scopes.
I would be willing to provide UI around picking the scopes... but I would need a way to show the scopes in a human readable format... I'm not aware of something in the OAuth spec for this, but maybe there is an extension.
+1 on this request.
Maybe leveraging the WWW-Authenticate header spec would make sense here to define the scope?
There seemed to be similar conversations prior to publishing the WWW-Authenticate piece of the MCP spec.
@collia39 how would you expect the usage of WWW-Authenticate to work?
I imagined something along the lines of the MCP server responding with a 401 and a header like below.
WWW-Authenticate: Bearer resource_metadata="https://my-auth-server.com", scope="profile email"
Then grabbing the "scope" param and using that when requesting a token.
@collia39 How is that different than using what the resource defines in its PRM?
@TylerLeonhardt - Ah, ok. Yes, you are correct. My resource metadata was improperly defined, which led to it defaulting to my authorization server's full set of supported scopes, rather than my resource server's required scopes. After fixing the metadata, VS Code is only requesting the scopes required by the resource server.
I'm curious about your line of thought around scopes_required vs scopes_supported. On one hand, I feel like if someone puts up a PRM file with scopes_required, thats what should be asked for under the general principle of least privilege, but at the same time, I can entirely see the logic behind going for scopes_supported, knowing that asking for all of these will ensure that anything that is needed from that endpoint will work and not get an unauthorized.
I'm kind of torn on this one myself as far as what the expected behavior should be...
@jescalan I don't think there's a scopes_required that is a part of the spec (unless I'm wrong)... there is only scopes_supported?