azure-sdk-for-net: DefaultAzureCredential does not use az cli login

In the old APIs we had AzureServiceTokenProvider to log in with Managed Identity. If you were running locally and had logged in with the az cli, AzureServiceTokenProvider would simply use your az session. This code worked locally, as long as you were logged in with az cli in the old APIs:

var tokenProvider = new AzureServiceTokenProvider();
keyVaultClient = new KeyVaultClient(new KeyVaultClient.AuthenticationCallback(tokenProvider.KeyVaultTokenCallback));
var secretValue = keyVaultClient.GetSecretAsync(keyVaultUrl, supersecretname).Result;

However, this does not work with the new APIs. For example, this code:

var client = new SecretClient(vaultUri: new Uri(keyVaultUrl), credential: new DefaultAzureCredential());
var secretValue = client.GetSecret(supersecretname);

throws this exception:

Exception has occurred: CLR/Azure.Identity.AuthenticationFailedException
An unhandled exception of type 'Azure.Identity.AuthenticationFailedException' occurred in Azure.Security.KeyVault.Secrets.dll: 'The DefaultAzureCredential failed to retrieve a token from the included credentials.
  EnvironmentCredential is unavailable Environment variables not fully configured. AZURE_TENANT_ID and AZURE_CLIENT_ID must be set, along with either AZURE_CLIENT_SECRET or AZURE_USERNAME and AZURE_PASSWORD. Currently set variables [  ].
  ManagedIdentityCredential is unavailable No managed identity endpoint found..
  SharedTokenCacheCredential is unavailable Token acquisition failed for user . To fix, re-authenticate through developer tooling supporting Azure single sign on..

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 8
Comments: 17 (5 by maintainers)

Most upvoted comments

@sm15455 Sorry, for the delay in information. We are actively working on this and hope to have a preview which enables using the azure cli login for authentication in Azure.Identity sometime in March.

schaabs on Feb 11, 2020

@flytzen Today we released a Azure.Identity 1.2.0-preview.1 which contains updates to the DefaultAzureCredential to use the Azure CLI logged in account when available. Please try out this new functionality and let us know if you have any questions or feedback.

Keep in mind that this feature is in preview, so some of the details like configuration are subject to change. This is the first of several previews we intend to ship with enhancements to the development time experience of the Azure.Identity library, with the ultimate goal of releasing them as GA sometime this summer.

schaabs on Mar 10, 2020

As a work-around, I created a token credential class that uses AzureServiceTokenProvider:

    public class AzureServiceTokenCredential : TokenCredential
    {
        public AzureServiceTokenCredential(string endPoint)
        {
            if (string.IsNullOrWhiteSpace(endPoint))
            {
                throw new ArgumentException("message", nameof(endPoint));
            }

            EndPoint = endPoint;
        }

        public string EndPoint { get; }

        public override AccessToken GetToken(TokenRequestContext requestContext, CancellationToken cancellationToken)
        {
            throw new NotImplementedException();
        }

        public override ValueTask<AccessToken> GetTokenAsync(TokenRequestContext requestContext, CancellationToken cancellationToken)
        {
            var tokenProvider = new AzureServiceTokenProvider();
            return new ValueTask<AccessToken>(tokenProvider
                .GetAccessTokenAsync(EndPoint, null, cancellationToken)
                .ContinueWith(task => {
                    return new AccessToken(task.Result, DateTimeOffset.MaxValue);
                }));
        }
    }

Then I can use this credential for other Azure services:

var blobAccountUri = new Uri(Config.StorageUrl);
var identity = new AzureServiceTokenCredential(Config.StorageUrl);
var blobClient = new BlobServiceClient(blobAccountUri, identity);

Maybe there is a better solution, but this works for me.

dfbaskin on Feb 20, 2020

Any updates on this issue? The new library offers a development experience that is worse compared to the old one. With the new library I’m forced to create environment variables on my machine, with the old one I just have to login uzing AZ CLI.

sm15455 on Feb 8, 2020

@logiclabs I have not confirmed this works. A colleague sent it to me. I am no longer badly affected by this problem. I do encounter some annoying credential validation checks this might fix. https://www.rahulpnath.com/blog/defaultazurecredential_from_azure_sdk/

jackfoxy on Apr 2, 2020

Ok, I found workaround. If you set ExcludeSharedTokenCacheCredential = true, this will skip your VS credentials and will go to CLI. DefaultAzureCredentialOptions defaultAzureCredentialOptions = new DefaultAzureCredentialOptions { ExcludeSharedTokenCacheCredential = true }; var credentials = new DefaultAzureCredential(defaultAzureCredentialOptions);

However, we still need to figure out why we can’t change the default tenant in VS Account Settings. There is “Apply filter” setting, after selecting the correct tenant, still get the “The access token is from the wrong issuer…” Keep in mind that the older: AzureServiceTokenProvider works with our VS account. As soon as we start using the DefaultAzureCredential is not working anymore. Maybe there was a change on how the VS credentials are used?

stotlyakov on Jun 2, 2020

Hi team, 1.2.0-preview.3 broke the Az login authorization again. 1.2.0-preview.1 works. Also, you would expect that if your Visual Studio 2019 dev account fail to authorize. It will pick as next option - the az CLI. But this is not the case. It fails if the tenant/subscription is incorrect with hard error: “The access token is from the wrong issuer…” and so on. So, know if I want to use the CLI as a workaround to authorize Azure App Configuration, I have to explicitly sign out from VS. Btw, With the latest VS 2019, you can’t change the “Default Azure Active Directory” option in Account settings. Using the drop down or even if i do “az account set -s {sub}” and i see that “isDefault”: true"

stotlyakov on Jun 1, 2020

FYI - We are discussing this internally and should have news in January.

jongio on Dec 6, 2019