[v0.10.0] Could not retrieve the token associated with Visual Studio Code. Works with v0.9.11

[lippertmarkus]

• VS Code Version: 1.64.2
• Azure Account Extension Version: v0.10.0
• OS Version: Windows_NT x64 10.0.19044

Steps to Reproduce:

We're having a extension which uses the Azure Account Extension as a dependency. With the new version v0.10.0 some users (but not all) in our tenant get the following error:

When those users downgrade to v0.9.11 the issue does not happen. Signing in and out again didn't help. Deleting the credentials stored in the Windows credential store also didn't.

Our extension uses the following snippet to get tokens:

const apiAzureAccount = vscode.extensions.getExtension<AzureAccountExtensionApi>('ms-vscode.azure-account')!.exports;
if (!(await apiAzureAccount.waitForLogin())) {
	await vscode.commands.executeCommand('azure-account.askForLogin');
}

const credential = new VisualStudioCodeCredential();
var token = await credential.getToken(tokenAudience, { tenantId: tenantID });

[lippertmarkus]

The following process seems to work for us:

1. Temporary downgrade the Azure Account Extension to v0.9.11 and reload the window
2. Run "Azure: Sign Out" and afterwards "Azure: Sign In"
3. Upgrade the Azure Account Extension back to v0.10.0 and reload the window

[wwlorey]

Hi @lippertmarkus, thanks for filing. What is the Azure: Authentication Library setting for the effected users? Also, are the OS and VS Code versions you listed the only versions you ran into this problem with?

Unfortunately I'm unable to reproduce this issue after creating a sample extension and using the API in the way you described. I tried on Mac and Windows using VS Code versions 1.65.0-insider and 1.64.2 respectively.

[lippertmarkus]

@wwlorey I checked a few affected users, and they all had ADAL set as authentication library, but many other users who don't have the problem also had ADAL set here. Also switching the affected users to MSAL didn't help with the issue. The only thing that helped is the process I mentioned in my last comment.

[wwlorey]

Thanks, @lippertmarkus. Do you know if those users are signing in with a tenant ID other than the default? Or if they're using a cloud other than general Azure (such as Azure China or Azure Germany)?

[lippertmarkus]

All affected and non-affected users are using the same tenant ID and general Azure.

[lippertmarkus]

It seems like authentication information stored by v0.10.0 is invalid or can't be retrieved. Today I tried using another account B in another tenant and tried using Sign Out and Sign In with v0.10.0 again. The status bar showed that I would be logged in with the correct account B but credential.getToken() still gave me tokens for account A I was logged in with before.
Again I needed to downgrade to v0.9.11 and sign out/sign in with this version to make it work.

[GusteB]

I assume we identified the issue.

Visual Studio Code Azure Account extension version 0.10.0 stores refresh token under a new name 'vscodems-vscode.azure-account' in Windows credential manager. Previously the name was 'VS Code Azure'. What happens is @azure/identity library is looking for credentials under the wrong name using keytar method getPassword.

Below are screenshots for credential manager.
v0.9.11:

v0.10.0:

[wwlorey]

Thanks, @GusteB that is very helpful. I filed Azure/azure-sdk-for-js#20500 to track this issue.

[KarishmaGhiya]

@wwlorey We wanted to know if the VS Code team will be reverting back the cache name change or would you want the @azure/identity library to support both the cache locations now? We are curious because the latter is a breaking change for our library.

[wwlorey]

Hi @KarishmaGhiya, we moved to using VS Code's secrets API for security reasons and we'd like to stick with that implementation.

Is it a requirement for the identity package to read the Account Extension's cache information directly from the credentials store going forward? The extension has an API in place that I think would be a better fit for this situation. That doesn't change the fact that it would be a breaking change for @azure/identity though - apologies for that.

[KarishmaGhiya]

@wwlorey Can you point us to the documentation on that VS Code's secrets API? Is it available publicly?

[bwateratmsft]

The SecretStorage class implements it; an instance is passed in the ExtensionContext given to the extension at activation.

[KarishmaGhiya]

• The 4 cache names linked in this screenshot - [v0.10.0] Could not retrieve the token associated with Visual Studio Code. Works with v0.9.11 #443 (comment) Are they different for different types of cloud? what does AzureCloud-1 , AzureCloud-2 etc represent? Will the cache names change with the type of cloud?

• Will the cache names change in the future with every Extension version?

• Is there an API for VS Code where we could read the cache names? We don't want to change the implementation for @azure/identity too much at least for the hotfix where we are reading the cache directly for the secrets. We need to know what caches to read.

• Does VS Code not use keytar anymore since moving to using VS Code's secrets API ?

@bwateratmsft @wwlorey

[wwlorey]

@KarishmaGhiya

The 4 cache names linked in this screenshot - #443 (comment) Are they different for different types of cloud? what does AzureCloud-1 , AzureCloud-2 etc represent? Will the cache names change with the type of cloud?

The cache names will change based on the type of cloud environment. Here are two examples of how we use the SecretStorage API. In both cases, we just provide the environment name (which was "AzureCloud" for that user) and VS Code appears to add additional information to the cache key. That isn't something we control in the extension.

vscode-azure-account/src/login/adal/tokens.ts

Line 62 in af40115

return await ext.context.secrets.get(environment.name);

vscode-azure-account/src/login/msal/cachePlugin.ts

Line 11 in af40115

const cachedValue: string | undefined = await ext.context.secrets.get((await getSelectedEnvironment()).name);

Will the cache names change in the future with every Extension version?

VS Code's implementation of SecretStorage dictates the exact cache key names. The only thing that would change the cache keys that the extension provides to VS Code is if the environment names for Azure clouds change again. For example: default Azure's environment name used to be "Azure" instead of "AzureCloud" (the latest name).

Is there an API for VS Code where we could read the cache names? We don't want to change the implementation for @azure/identity too much at least for the hotfix where we are reading the cache directly for the secrets. We need to know what caches to read.

According to VS Code's API docs there isn't currently a way to get cache names 😕 It's possible to request that feature from the VS Code team but I don't think it would be released fast enough for a hot fix and I would wager it isn't a path they want to go down.

Does VS Code not use keytar anymore since moving to using VS Code's secrets API ?

It looks like VS Code uses keytar under the hood for their SecretStorage.
Related: here's the issue tracking VS Code's support for that API microsoft/vscode#112249

[spboyer]

@fiveisprime

[wwlorey]

Here's another error resulting from this problem:

Stored credentials not found. Need to authenticate user in VSCode Azure Account. See the troubleshooting guide for more information. https://aka.ms/azsdk/net/identity/vscodecredential/troubleshoot

[alex-frankel]

Hey folks - I'm having a bit of trouble following the thread :)

@wwlorey -- do you all have a sense of when this will be resolved? Will it be done via an update to the Azure Account extension?

[wwlorey]

@alex-frankel we're working with the SDK team on this and will update this thread when we have an idea of the timeline.

[aaronsmith1234]

Thanks all, our org just hit this as well, so we are interested in resolution. Thanks!

[lippertmarkus]

Would be great if you could at least provide a way to write the legacy credentials with the old name as a workaround. The VSC Extension API versioning (getExtension('ms-vscode.azure-account')!.exports).getApi('1.0.0')) is exactly meant for that - to prevent breaking changes from affecting all dependent extensions. You could introduce a 0.9.0 API version using the old logic.

I need to tell all our users since 4 months "Please downgrade to 0.9.11" every few weeks when their tokens expire. And new users can't just install our extension and get started but instead need to first downgrade the Azure Account extension. Not really a great experience.

[GregorieCalderon]

Any news on this issue?

Currently experiencing and i can not get around it at all. Even a downgrade on my end did nothing.

[mike-gormley]

Another bump. Behind a proxy, only work around we had is reverting Azure Account extension to 0.9.11 and 0.4.0 on the Azure Resources extension. Seems to affect other extensions too e.g. Bicep but this is as far we've got with our investigations and have reverted more or less to NOT using VS Code Azure extensions family and going for CLI commands instead. :(

[anthonywhite]

Same here as others working behind a proxy. Have not been able to sign into Azure from VS Code for months now, even with extension downgrades. Which basically means our local development of Logic Apps Standard is ended. No Azure connection -> no Logic Apps connectors -> no local designer -> no integration with VSCode or Git.

We are back to working in the portal and copying and pasting json into our repos. Really marvellous.

=================================================================
UPDATE 08-DEC-2022 This suggestion is working for us:
#676 (comment)

hope it help others...

[KarishmaGhiya]

Hello, from the Azure SDK side, if you are using @azure/identity SDK for authentication, we recommend users to use Azure CLI for authentication as the workaround suggested in the troubleshooting guide.
The work for Visual Studio Credential is being tracked in this issue - Azure/azure-sdk-for-js#22904 and is planned for the next 6 months.

Let me know if you have any questions.

[alexweininger]

Same here as others working behind a proxy. Have not been able to sign into Azure from VS Code for months now, even with extension downgrades. Which basically means our local development of Logic Apps Standard is ended. No Azure connection -> no Logic Apps connectors -> no local designer -> no integration with VSCode or Git.

We are back to working in the portal and copying and pasting json into our repos. Really marvellous.

================================================================= UPDATE 08-DEC-2022 This suggestion is working for us: #676 (comment)

hope it help others...

@anthonywhite thank you for letting us know this workaround works for you. Just to confirm, this fix works on the latest version of the Azure Account extension?

[anthonywhite]

@alexweininger yes am using 0.11.2

[corytomlinson]

The documentation for the workaround is entirely unclear. Could the team please provide a working example using Python showing to to authenticate using this method?

[alexweininger]

@corytomlinson I'm not sure I understand what you're trying to do. Could you explain a bit more about your use case?

Also, which workaround are you referring to? The workaround mentioned immediately above is for fixing issues with authenticated behind a proxy.