Re-enable VisualStudioCodeCredential for Windows after VSCode adopts BrokeredAuthentication (WAM)

[billwert]

trafficstars

VisualStudioCodeCredential will depend on a new authentication tool which replaces the Azure Account extension in Visual Studio Code. This tool is not yet built; more details to come. [https://github.com/microsoft/vscode/issues/178740]

Reminder: when added back to DAC, the default failure mode should be CredentialUnavailableException, as with other dev credentials in the chain.

[Kiechlus]

Is there a timeline on this?

[github-actions[bot]]

Hi @billwert, we deeply appreciate your input into this project. Regrettably, this issue has remained unresolved for over 2 years and inactive for 30 days, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.

[joshfree]

@scottaddie could you add a link to the VSCode MSAL/WAM github issue

[joshfree]

Related: https://github.com/microsoft/vscode/issues/178740

[joshfree]

Scoping this to Windows-only initially

[scottaddie]

Now that WAM is the default authN mechanism in VS Code desktop, we can explore restoration of SSO with VS Code for Windows customers. Such a feature would fill the gap left behind with the deprecation of VisualStudioCodeCredential. One idea is to use a silent, broker-enabled instance of InteractiveBrowserCredential.

[joshfree]

Gist for April Beta release https://gist.github.com/christothes/f8a0dc6249261cb36a6c452717c4e932

[joshfree]

Related work on the VS Code and Azure MCP Server side of this puzzle is tracked here: https://github.com/Azure/azure-mcp-pr/issues/245