🚨 Azure Error Guide: 'DefaultAzureCredential failed to retrieve a token' — Fix the Credential Chain

Overview

The Azure Identity SDKs (DefaultAzureCredential) try a chain of credential sources in order and throw when every one fails. The aggregate error lists each attempt:

DefaultAzureCredential failed to retrieve a token from the included credentials.
Attempted credentials:
	EnvironmentCredential: EnvironmentCredential authentication unavailable.
	  Environment variables are not fully configured.
	ManagedIdentityCredential: ManagedIdentityCredential authentication unavailable.
	  No managed identity endpoint found.
	AzureCliCredential: Azure CLI not installed or not logged in.
	  Please run 'az login' to set up an account.
To mitigate this issue, please refer to the troubleshooting guidelines here at
https://aka.ms/azsdk/net/identity/defaultazurecredential/troubleshoot.

The language differs slightly per SDK (.NET, Python azure-identity, JS @azure/identity, Java), but the shape is the same: a chain that exhausted every option.

Symptoms

• App works locally but throws DefaultAzureCredential failed once deployed to App Service, Functions, AKS, or a VM.
• Accessing Key Vault, Storage, or another resource fails at token acquisition, before any resource-level authorization.
• The error lists ManagedIdentityCredential: ... No managed identity endpoint found in a hosted environment.
• Locally it fails with AzureCliCredential: ... please run 'az login'.
• A token is obtained but the subsequent call returns 403 — a different, RBAC problem downstream of a successful credential.

Common Root Causes

• No managed identity assigned. The hosting resource (Web App, Function, VM, AKS pod) has no system- or user-assigned identity, so ManagedIdentityCredential finds no endpoint.
• User-assigned identity not selected. Multiple identities exist but the code didn’t specify a managedIdentityClientId, so the SDK can’t pick one.
• Not logged in locally. On a dev machine, az login / Connect-AzAccount was never run or the session expired, so AzureCliCredential fails.
• Incomplete environment variables. EnvironmentCredential needs AZURE_TENANT_ID, AZURE_CLIENT_ID, and AZURE_CLIENT_SECRET (or cert) — a partial set is ignored.
• Wrong tenant/authority. The credential targets a different tenant than the resource, so no valid token is issued.
• Downstream RBAC (not credential) failure. A token is acquired but the identity lacks the data-plane role (e.g. Key Vault Secrets User), producing a 403 that looks similar but is a different problem.

Diagnostic Workflow

Confirm whether a managed identity exists on the hosting resource (read-only):

# App Service / Functions: is an identity assigned?
az webapp identity show --resource-group <rg> --name <app> --output json

# VM: system- and user-assigned identities.
az vm identity show --resource-group <rg> --name <vm> --output json

For a user-assigned identity, get the clientId the code must specify:

az identity show --resource-group <rg> --name <uami> --query "{clientId:clientId, principalId:principalId}" --output table

Locally, verify you are logged in and in the right tenant:

# AzureCliCredential relies on this being valid.
az account show --query "{user:user.name, tenant:tenantId, sub:id}" --output table

Once a token is obtained, confirm the identity’s role at the target scope (rules out the 403 variant):

# Does the identity have the needed data-plane role on the resource?
az role assignment list --assignee <principalId-or-clientId> --all \
  --query "[].{role:roleDefinitionName, scope:scope}" --output table

Example Root Cause Analysis

A .NET API read secrets from Key Vault using DefaultAzureCredential. It worked on developer laptops but, once deployed to an App Service, every request failed with DefaultAzureCredential failed to retrieve a token, and the chain reported ManagedIdentityCredential: ... No managed identity endpoint found.

The message was decisive: in the hosted environment the SDK expected a managed identity but found none. az webapp identity show returned null — no system-assigned identity had ever been enabled on the Web App. Locally it had worked only because AzureCliCredential picked up the developer’s az login session, which does not exist in App Service.

The fix was to enable a system-assigned identity on the Web App (az webapp identity assign) and grant it the Key Vault Secrets User role on the vault. On redeploy, ManagedIdentityCredential acquired a token and Key Vault access succeeded. Root cause: no managed identity on the hosting resource, so the credential chain had nothing to use in production.

Prevention Best Practices

• Enable a managed identity on every hosting resource that uses DefaultAzureCredential, and prefer it over stored secrets.
• Pass the user-assigned client ID explicitly (ManagedIdentityClientId / managedIdentityClientId) when more than one identity could apply.
• Grant least-privilege data-plane roles at the resource scope (e.g. Key Vault Secrets User, Storage Blob Data Reader) so a valid token also authorizes the call.
• Keep local dev consistent with az login to the correct tenant, or use a scoped dev service principal via environment variables.
• Enable identity logging (AZURE_LOG_LEVEL / SDK logging) to see which credential in the chain failed and why.
• Consider a narrower credential (ManagedIdentityCredential directly) in production to fail fast instead of silently trying laptop-only options.

Quick Command Reference

# Enable a system-assigned identity on a Web App.
az webapp identity assign -g <rg> -n <app>

# Show assigned identities.
az webapp identity show -g <rg> -n <app>
az vm identity show -g <rg> -n <vm>

# Get a user-assigned identity's clientId for the code.
az identity show -g <rg> -n <uami> --query clientId -o tsv

# Confirm local login for AzureCliCredential.
az account show

# Grant a data-plane role at resource scope.
az role assignment create --assignee <principalId> --role "Key Vault Secrets User" --scope <vaultId>

Conclusion

DefaultAzureCredential failed to retrieve a token means every credential in the chain came up empty — most often because the hosting resource has no managed identity, or because you are not logged in locally. Read the per-credential lines in the error: they tell you exactly which source failed. Enable a managed identity in production, az login in development, specify the client ID when multiple identities exist, and remember that a 403 after a successful token is a separate RBAC fix, not a credential one.