Plumbs an optional 'resource' field through IAuthenticationService get/createSession options and the authIssuers proposal so MCP authentication can request audience-restricted tokens. mainThreadMcp now forwards authDetails.resourceMetadata.resource into both calls.
In the microsoft-authentication extension, the resource is threaded into MSAL's acquireTokenInteractive, acquireTokenByDeviceCode, and acquireTokenSilent. Bumps @azure/msal-node and @azure/msal-node-extensions to ^5.1.5; adapts to ServerAuthorizationCodeResponse -> AuthorizeResponse and fromNativeBroker -> fromPlatformBroker renames.
Adds tests verifying that getSessions/createSession forward 'resource' to the provider, and that each MSAL flow (default, protocol handler, device code) forwards 'resource' to the underlying MSAL call.
Disabled protocol handlers and registry updates on Windows in portable mode.
Added API proposal to detect if VS Code is running in portable mode from extensions.
Skipped protocol redirect in GitHub authentication in portable mode.
* Initial plan
* Remove web worker support from microsoft-authentication extension
- Remove browser entry point from package.json
- Remove browser webpack configuration
- Remove browser-specific scripts (compile-web, watch-web)
- Remove src/browser/ directory with browser-specific implementations
- Remove ExtensionHost.WebWorker enum value
- Remove supportsWebWorkerExtensionHost flags from all flows
- Simplify authProvider.ts by removing web worker detection logic
- Remove web worker test case from flows.test.ts
- Successfully compiled with 0 errors
Co-authored-by: TylerLeonhardt <2644648+TylerLeonhardt@users.noreply.github.com>
* couple references
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
* Enable the broker in macOS
Fixes https://github.com/microsoft/vscode/issues/260158
* for testing
* better globbing
* guh
* guh
* delete
* log it all
* let's just log everything
* Only do on supported OS/Arches
* Add a console.log
* look at VSCODE_ARCH
* add msal files
* add entitlement maybe here
* actually it's probably here
* build: bundle msal libs for x64 and arm64
* revert that
* try again
* try adding $(AppIdentifierPrefix)
* temp: add debuggee entitlements
* bump msal and pass in redirect uri on macOS
* revert entitlement files
* forgot the .helper
* Allow PII for the output channel only
* use unsigned option
---------
Co-authored-by: deepak1556 <hop2deep@gmail.com>
* `issuer` -> `authorizationServer` refactor
Also:
* adds `authorizationServerGlobs` to the authentication contribution schema
* removes ugly MCP issuer hack and instead plumbs the authorizationServer down to the new auth providers
MSAL node made `clearCache` synchronous 🎉 so we can safely depend on it for clearing the cache.
> Context: The default behavior of MSAL's internal cache is that it is a union with what's in the persistant cache (secret storage) but what _we_ want is that secret storage is the source of truth, so every time we receive an update to secret storage, we clear the in-memory cache to get the data from the persistant cache.
Also bumps msal-node-extensions while we're at it.
This adopts the `NativeBrokerPlugin` provided by `@azure/msal-node-extensions` to provide the ability to use auth state from the OS, and show native auth dialogs instead of going to the browser.
This has several pieces:
* The adoption of the broker in the microsoft-authentication extension:
* Adding `NativeBrokerPlugin` to our PCAs
* Using the proposed handle API to pass the native window handle down to MSAL calls (btw, this API will change in a follow up PR)
* Adopting an AccountAccess layer to handle:
* giving the user control of which accounts VS Code uses
* an eventing layer so that auth state can be updated across multiple windows
* Getting the extension to build properly and only build what it really needs. This required several package.json/webpack hacks:
* Use a fake keytar since we don't use the feature in `@azure/msal-node-extensions` that uses keytar
* Use a fake dpapi layer since we don't use the feature in `@azure/msal-node-extensions` that uses it
* Ensure the msal runtime `.node` and `.dll` files are included in the bundle
* Get the VS Code build to allow a native node module in an extension: by having a list of native extensions that will be built in the "ci" part of the build - in other words when VS Code is building on the target platform
There are a couple of followups:
* Refactor the `handle` API to handle (heh) Auxiliary Windows https://github.com/microsoft/vscode/issues/233106
* Separate the call to `acquireTokenSilent` and `acquireTokenInteractive` and all the usage of this native node module into a separate process or maybe in Core... we'll see. Something to experiment with after we have something working. NEEDS FOLLOW UP ISSUE
Fixes https://github.com/microsoft/vscode/issues/229431
* Use `@azure/ms-rest-azure-env` as official reference of endpoints
* Allow better configuration of custom clouds (these are new so it is ok to change the settings without migration)
Also clean up:
* querystring -> URLSearchParams (getting rid of a package dependency in the web)
* handle `workbench.getCodeExchangeProxyEndpoints` in one place