Create mechanism for fetching access token

[scottaddie]

High-level summary: The Azure Identity client libraries for .NET, Java, JavaScript, and Python offer a VisualStudioCodeCredential class to support SSO with VS Code. In current state, the credential type no longer works in any of these languages. The VisualStudioCodeCredential requires a mechanism to fetch an Entra access token from VS Code if the user has logged in with their credentials.

Context and background: Today, the Azure Identity libraries enable fetching credentials from developer tools (such as Azure CLI, Azure PowerShell, Azure Developer CLI, and Visual Studio) via invoking the CLI or a sidecar CLI that returns an access token if the user has logged into that tool. VS Code doesn't currently expose such a mechanism.

The northstar for developer tools is to adopt OneAuth-MSAL as their underlying implementation for 1P Entra authN. Integration involves taking a native dependency on OneAuth-MSAL. For shipping developer tools, this is manageable, but it's a big developer experience challenge for the Azure Identity libraries, especially for languages like Go. Libraries that cannot reasonably include this native dependency need to rely on the dev tool to expose some mechanism to fetch tokens from the currently logged in account.

/cc: @isidorn @christothes @chlowell

[TylerLeonhardt]

As I mentioned to Chris, if you absolutely wanna bring back the VisualStudioCodeCredential, you can:

1. write a VS Code extension that gets the access token and dumps it somewhere on disk
2. read it from the Azure SDK side With VS Code open, you can continue "refreshing" the token.

If VS Code isn't open and the token is expired, trigger the opening of VS Code which will activate this extension and do the above.

You can do this all with existing APIs.

Also, Azure Account was (indirectly) the provider for this before so some Azure extension could continue being the provider for this rather than VS Code directly.

I would rather you do this, then we have some backdoor CLI in VS Code. We are not an auth provider for other processes. We are only an auth provider for VS Code extensions.

[scottaddie]

@TylerLeonhardt I appreciate the suggestions, but each of these 2 proposed solutions yields a clunky developer experience. I'd like to think we can do better. The Azure SDK team isn't in the business of creating and owning VS Code extensions. Furthermore, VisualStudioCodeCredential must be able to fetch the access token even if VS Code isn't running.

Note that an extension/plugin isn't needed for the other major dev tools. They each ship a token retrieval mechanism, and that model has worked exceptionally well. Is there any official security review backing that explains why VS Code is barred from the approach used in these other tools? Are there any other potential solutions you can think of?

Without a solution in place, VS Code continues to offer a degraded debug and run experience (littered with sign-in prompts) compared to other dev tools, like Visual Studio, Azure PowerShell, Azure CLI, Azure Developer CLI, etc. This feature will plug this gap and improve the Azure developer experience in VS Code, thereby helping to delight our shared customer base.

[joshfree]

Hey @TylerLeonhardt thanks so much for helping us investigate this ask!

Just to be clear, we're not prescribing an exact solution, rather we want to engage and help brainstorm what a potential solution could look like that will help VSCode customers avoid having to login again and again and again...; Our first choice obviously is to enable this to work even after VSCode has been closed, but we understand that if this is not feasible that the mainline scenario is to be able to fetch a token while VSCode is running and developers are running/debugging their application code.