Azure.Identity: VisualStudioCodeCredential causes difficult to debug issues when using a live account

[allanlw]

Summary: When using the DefaultAzureCredential (and therefore VisualStudioCodeCredential), and being logged into VSCode with an Azure account where the login is via Microsoft Live leads to tenant errors unless the tenant is explicitly set in the VSCode options.

Attempting to run the following code:

TokenCredential credential = new DefaultAzureCredential();
var rmClient = new ResourcesManagementClient(subscriptionId, credential);
var tenantId = (await rmClient.Subscriptions.GetAsync(subscriptionId)).Value.TenantId;

Gives me the following error:

[2021-03-14T06:46:11.669Z]
[2021-03-14T06:46:11.669Z] Content:
[2021-03-14T06:46:11.670Z] {"error":{"code":"InvalidAuthenticationTokenTenant","message":"The access token is from the wrong issuer 'https://sts.windows.net/f8cdef31-a31e-4b4a-93e4-5f571e91255a/'. It must match the tenant 'https://sts.windows.net/<MY TENANT GUID>/' associated with this subscription. Please use the authority (URL) 'https://login.windows.net/<MY TENANT GUID>' to get the token. Note, if the subscription is transferred to another tenant there is no impact to the services, but information about new tenant could take time to propagate (up to an hour). If you just transferred your subscription and see this error message, please try back later."}}

You'll note that f8cdef31-a31e-4b4a-93e4-5f571e91255a is the default dummy tenant for Microsoft live accounts, which is sort of documented here.

Setting the azure.tenant seting in the VSCode Azure login package solves the problem. Logging out of VSCode Azure login also worked for me because it would then pick up my Azure CLI credentials, which automatically have the right tenant ID.

I believe this is a bug in Azure.Identity because I have no other issues using the VSCode azure login plugin without explicitly setting the tenant ID.

Environment:
VSCode version: 1.54.2
VSCode Azure Account plugin version: 0.97
Azure.Identity version: 1.3.0
zure.ResourceManager.Resources version: 1.0.0-preview.2

See also #17235 and even #11559 which are perhaps related because it is using the live dummy tenant id but that's not mentioned in the thread.

[jsquire]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[christothes]

Hi @allanlw - Does this reproduce if you set ExcludeSharedTokenCacheCredential to true in the DefaultAzureCredentialOptions?

[allanlw]

@christothes That does not fix the problem. ExcludeVisualStudioCodeCredential=true does though.

[christothes]

Thanks @allanlw - Then it sounds like the VisualStudioCredential is attempting to login with a different identity.

[allanlw]

Well, it's the same credentials. The problem is that the tenant is wrong.

VsStudioCodeCredentials reads the tenant from the VSCode config. Setting my tenant there fixes the issue.

However, the VS code help for the azure.tenant setting says: A specific tenant to sign in to. The default is to sign in to the common tenant and use all known tenants. (note ALL known tenants) This is presumably why my tenant is showing up as f8cdef31-a31e-4b4a-93e4-5f571e91255a as mentioned at the top. Before using Azure.Identity I had left this unset, which is the default, as it is not set when logging in using the Azure: Sign In command, and all parts of using azure in VSCode function fine.

You can see this in action in:

azure-sdk-for-net/sdk/identity/Azure.Identity/src/VisualStudioCodeCredential.cs

Line 43 in fcb90d3

_tenantId = options?.TenantId ?? "common";

and

https://github.com/microsoft/vscode-azure-account/blob/efbaeb4a61e30f5856fe5288960ae837e198cc8e/src/azure-account.ts#L893

For all the azure plugins in VS code, they work fine with it unset.

It would seem the implementation in vscode does a two-stage login if the tenant is the common tenant:

https://github.com/microsoft/vscode-azure-account/blob/efbaeb4a61e30f5856fe5288960ae837e198cc8e/src/azure-account.ts#L313-L320

and:

https://github.com/microsoft/vscode-azure-account/blob/efbaeb4a61e30f5856fe5288960ae837e198cc8e/src/azure-account.ts#L967-L987

I might be missing something, but I don't see the same logic occurring in Azure.Identity, which is presumably why I was left with the "common" tenant.

Maybe this bug is a documentation and/or error message one, but regardless it was difficult to debug and a bad user experience.

[allanlw]

Note: this comment exactly matches my experience, except for VS Code. #17235 (comment)

If you delete ~.Identity and sign into Visual Studio and/or Azure CLI using the preferred account, does this work for you?

• No for: var cred = new DefaultAzureCredential();
• No for: var cred = new DefaultAzureCredential(new DefaultAzureCredentialOptions { ExcludeSharedTokenCacheCredential = true });
• Yes for: var cred = new VisualStudioCredential(new VisualStudioCredentialOptions { TenantId = "d304cb51-c9ec-4c15-bfdd-a8d6e80018ab" });

In my case I am only using one MSA account.

[christothes]

Hi @allanlw Thanks for providing such great context for this issue.

I spent some time looking into this problem. The bad news is that, in the short term, there isn't a great alternative to providing the TenantId hint to the credential options (or to VSCode's options). However, there is some longer range feature work we are considering that would address this problem more generally when trying to authenticate to services that support providing the tenant Id back as part of the WWW-Authenticate header. Assuming we added support to handle these challenges, scenarios like this would "just work".

For example, services like Key Vault and Storage return back an authorization_uri value in the challenge header that indicates which tenant to use. Given this context we could automatically use this tenant when acquiring the auth token.

I created issue #20203 to track some work to improve the error experience for scenarios like this.

[christothes]

#19404