search

microsoft / vscode-azure-account

Common Azure Login extension for VS Code
https://marketplace.visualstudio.com/items?itemName=ms-vscode.azure-account
Other
139 stars 129 forks source link

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

Open lippertmarkus opened 2 years ago

lippertmarkus commented 2 years ago

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: image

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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

lippertmarkus commented 2 years ago

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 commented 2 years ago

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: 0 9 11 v0.10.0: 0 10 0

wwlorey commented 2 years ago

Thanks, @GusteB that is very helpful. I filed https://github.com/Azure/azure-sdk-for-js/issues/20500 to track this issue.

KarishmaGhiya commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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

bwateratmsft commented 2 years ago

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

KarishmaGhiya commented 2 years ago

@bwateratmsft @wwlorey

wwlorey commented 2 years ago

@KarishmaGhiya

The 4 cache names linked in this screenshot - https://github.com/microsoft/vscode-azure-account/issues/443#issuecomment-1048018144 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.

https://github.com/microsoft/vscode-azure-account/blob/af40115544e7ef52c38d97df332a1b09122ac1a7/src/login/adal/tokens.ts#L62

https://github.com/microsoft/vscode-azure-account/blob/af40115544e7ef52c38d97df332a1b09122ac1a7/src/login/msal/cachePlugin.ts#L11

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 https://github.com/microsoft/vscode/issues/112249

spboyer commented 2 years ago

@fiveisprime

wwlorey commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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

lippertmarkus commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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: https://github.com/microsoft/vscode-azure-account/issues/676#issuecomment-1338281972

hope it help others...

KarishmaGhiya commented 1 year ago

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 - https://github.com/Azure/azure-sdk-for-js/issues/22904 and is planned for the next 6 months.

Let me know if you have any questions.

alexweininger commented 1 year ago

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 commented 1 year ago

@alexweininger yes am using 0.11.2

corytomlinson commented 1 year ago

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 commented 1 year ago

@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.