A valid token can still be headed to the wrong host.

The setting beside the token is part of the security boundary.

Visual Studio Code 1.140 adds a proposed authorizationServer field to AuthenticationSession. An authentication provider can now tell an extension which OAuth authorization server issued the session. The release notes describe the practical case: an extension that talks to public GitHub and a GitHub Enterprise host can pair the credential with the deployment instead of reading a separate host setting that the user can change on its own.^[1]

That pairing closes a small but dangerous gap. A token can be real and usable while the request route is wrong. If destination selection lives in mutable configuration, changing the setting can detach a credential from the deployment that issued it.

Do not ask only, "Is this credential valid?" Ask, "Which service route does this session belong to?"

The issuer is not the API endpoint.

The proposed field identifies an OAuth authorization server. The VS Code release notes warn that it is not a REST API endpoint or a resource audience. Extension authors still need a reviewed mapping from issuer to service endpoints. The field's presence also does not identify a session as enterprise because the built-in GitHub provider supplies it for public GitHub sessions too.^[1]

This distinction matters because three names can appear in one request path. The issuer says who created the session. The API host says where the request will be sent. The resource or audience says where the access token is intended to work. Treating those names as synonyms removes checks rather than simplifying them.

Multiple authorization servers need an identity check.

OAuth 2.0 Security Best Current Practice says that a client interacting with more than one authorization server needs a defense against mix-up attacks. Its preferred countermeasure uses issuer identification. The document describes the attack goal as tricking a client into sending credentials to a compromised authorization server instead of the expected authorization or resource server.^[2]

The VS Code proposal is not a complete implementation of every OAuth defense. It gives an extension one useful fact from the authentication provider. The extension still owns endpoint mapping, request construction, audience handling, token storage, and error behavior.

Scope does not tell you where the token belongs.

RFC 8707 separates the requested access from the protected resource that will receive the token. It notes that scope often says what access is requested, such as reading channels, while a resource indicator says where that access will be redeemed. The authorization server can then mint a token for the intended resource and restrict its audience.^[3]

That gives an editor extension a clean review order:

1. Read the issuer from the authentication session when the provider supplies it.
2. Resolve that issuer through a reviewed, fixed mapping.
3. Choose the API endpoint from the mapping, not an unrelated mutable setting.
4. Request or inspect the intended resource and audience when the provider supports it.
5. Refuse unknown issuers, unmapped deployments, and host mismatches.