Photo by Matt Halls on Unsplash

Introduction

I have been using the DefaultAzureCredential class for a long time without understanding how it works. So, I jotted down my notes and learnings in this write-up for future me — and maybe you will find it useful too.

TokenCredential

TokenCredential is the abstract base class representing a source of authentication tokens for Azure services. Many classes derive from TokenCredential but the most interesting ones are DefaultAzureCredential and ChainedTokenCredential.

I’m using package version :Azure.Identity v1.20.0

DefaultAzureCredential

This class is a pre-built chain covering the most common authentication methods. When using DefaultAzureCredential to acquire a token, the class attempts to acquire a token via each of the below credentials, in the following order, stopping when one provides a token:

• EnvironmentCredential
• WorkloadIdentityCredential
• ManagedIdentityCredential
• VisualStudioCredential
• VisualStudioCodeCredential (enabled by default for SSO with VS Code on supported platforms when Azure.Identity.Broker is installed)
• AzureCliCredential
• AzurePowerShellCredential
• AzureDeveloperCliCredential
• InteractiveBrowserCredential (not included by default; can use brokered authentication if Azure.Identity.Broker is installed)

source: DefaultAzureCredential Class (Azure.Identity) — Azure for .NET Developers | Microsoft Learn

DefaultAzureCredential with Exclusion

DefaultAzureCredential also supports options that allow you to exclude credentials from evaluation. This is useful if you don’t want to use certain credentials, for example, when running my function locally, I don’t want to use the VisualStudio or VisualStudioCode credential as I prefer AzureCliCredential.

new DefaultAzureCredential(
new DefaultAzureCredentialOptions
{
ExcludeVisualStudioCodeCredential = true,
ExcludeVisualStudioCredential = true
});

ChainedTokenCredential

In some cases, you will know exactly which credentials you want to use. ChainedTokenCredential is very useful in such cases. It evaluates only the credentials you explicitly specify, in the order provided. I use this locally. For example, below I choose to use only CLI and VS credentials when my function is running locally.

new ChainedTokenCredential(
new AzureCliCredential(),
new VisualStudioCredential()
));

Why Managed Identity fails locally but works in Azure

DefaultAzureCredential attempts ManagedIdentityCredential (which is unavailable locally — IMDS timeout) and falls through to developer credentials — VS, CLI, etc (refer the table above). The first credential in the chain that can successfully acquire a token is used.

Note: DefaultAzureCredential evaluates
EnvironmentCredential, then WorkloadIdentityCredential,
followed by ManagedIdentityCredential.

There is no native way to emulate or impersonate a managed identity locally. IMDS (169.254.169.254) is a hypervisor-level endpoint that only exists on Azure compute. It is physically not present on your laptop. The common alternative would be to use a service principal with similar privileges as the UAMI to test your function.

In Azure: The chain gets to ManagedIdentityCredential, IMDS responds, token acquired. Everything below it never runs.

Locally: IMDS doesn’t exist, so ManagedIdentityCredential times out and falls through.

When DefaultAzureCredential is used, the evaluation would like this (assuming none of the credentials are able to provide a token) —

//When running locally there is no IMDS to supply managed identity token
//Assuming VS and other credentials don’t have access to the resource.
//This is how DefaultAzureCredentials evaluates the chain
EnvironmentCredential → skipped (env vars not set)
WorkloadIdentityCredential → skipped (not configured)
ManagedIdentityCredential → unavailable/failure (no IMDS endpoint locally)
VisualStudioCredential → failed
VisualStudioCodeCredential → failed
AzureCliCredential → failed
AzurePowerShellCredential → failed
AzureDeveloperCliCredential → failed
InteractiveBrowserCredential → Not included by default (must be explicitly enabled)

How to configure for local debugging

One approach is to use a factory that returns different credential implementations depending on the execution environment.

For example, when the environment is local, a factory can return a DefaultAzureCredential where you can exclude Visual Studio and Visual Studio Code credentials if you favour AzureCliCredential. Or, better still, if you want to use only Azure CLI or VS credentials, it can return a ChainedTokenCredential with just those two credentials, as shown below

new ChainedTokenCredential(
new AzureCliCredential(),
new VisualStudioCredential()
)

When the environment is Azure, it can just return a DefaultAzureCredential instance or a ChainedTokenCredential as discussed earlier if you are sure about the credential you want to use. If you want to use a specific credential, it can be used directly without DefaultAzureCredential or ChainedTokenCredential. For example, here I’m using a specific credential class —

new ManagedIdentityCredential(
ManagedIdentityId.FromUserAssignedClientId(«your-uami-ClientId»)))

A sample flow will look as below when you use a ChainedTokenCredential as shown previously —

AzureCliCredential → acquire token - SUCCESS
VisualStudioCredential → skipped

Notice that only the two credentials mentioned in the ChainedTokenCredential chain are evaluated.

AZURE_CLIENT_ID influence in identity selection

Many Azure resources can have both System Assigned Managed Identity (SAMI) and User Assigned Managed Identity (UAMI). It is crucial to understand how the AZURE_CLIENT_ID environment variable influences how Azure SDK authentication selects a managed identity. This is not always obvious, and I could not find it clearly documented anywhere

AZURE_CLIENT_ID set?
│
├── YES
│ │
│ └── Which credential in code?
│ │
│ ├── DefaultAzureCredential()
│ │ └── ✅ UAMI (via AZURE_CLIENT_ID)
│ │
│ ├── ManagedIdentityCredential(id)
│ │ └── ✅ UAMI (via explicit id, ignores AZURE_CLIENT_ID)
│ │
│ └── ManagedIdentityCredential()
│ └── ⚠️ SAMI (ignores AZURE_CLIENT_ID)
│
└── NO
│
└── Which credential in code?
│
├── DefaultAzureCredential()
│ └── ⚠️ SAMI
│
├── ManagedIdentityCredential(id)
│ └── ✅ UAMI (via explicit id)
│
└── ManagedIdentityCredential()
└── ⚠️ SAMI (no id provided)

Key rule: ManagedIdentityCredential() does not use
AZURE_CLIENT_ID to select a user-assigned managed identity.
Only DefaultAzureCredential does

Note: the flowchart assumes a System Assigned Managed Identity is present. In cases where SAMI is absent and no UAMI is explicitly provided, token acquisition will fail

Authentication between a Function App and its AzureWebJobsStorage is an independent flow not covered by the flowchart above. See [Using Managed Identity for Function App Authentication with its Storage Account] for a detailed walkthrough.

Summary

DefaultAzureCredential is environment-aware by design — the same code uses managed identity in Azure and falls through to developer credentials locally. This means local failures don’t always predict Azure failures, and the identity that succeeds locally may be in a different tenant than your Azure resources. For local testing against tenant-specific resources, ensure az login --tenant <tenant-id> is used explicitly, not just any az login. To test managed identity behaviour you must deploy, or substitute a service principal with matching roles via EnvironmentCredential.

Reference — Authentication best practices with the Azure Identity library for .NET — .NET | Microsoft Learn

I checked whether the UAMI had necessary RBAC roles to work on AzureWebJobsStorage — it had. So, I wasn’t sure what the issue was.

Analyzing further, I realized I had skipped a few mandatory variable settings to enable UAMI based authentication to AzureWebJobsStorage (setting the environment variable AzureWebJobsStorage__accountName alone does not suffice)

Steps to enable UAMI access to AzureWebJobsStorage

Enabling UAMI access to AzureWebJobStorage involves changes in Terraform (when the Function App is created), the App Settings (Environment variables) and finally the Role Based Access.

Terraform

If for some reason you want to use UAMI to authenticate with AzureWebJobsStorage, then Terraform block **functionAppConfig.deployment.storage.authentication**: should look like below

Note: I am using Flex Consumption tier

authentication = {
type = “userassignedidentity”
userAssignedIdentityResourceId = “”
}

This tells the platform to use UAMI for the deployment package blob container — the part that isn’t controlled by app settings.

App settings

Once the Function App is deployed with usermanagedidentity as authentication type (terraform), ensure the below variables are set in the Function App’s Environment variables

AzureWebJobsStorage__accountName =
AzureWebJobsStorage__credential = managedidentity
AzureWebJobsStorage__clientId =

All three settings are mandatory.

RBAC

This is the final bit. We have the Function App deployed, environment variables set, next, the UAMI needs privilege to access the storage account.

Provide Storage Blob Data Owner owner role to the UAMI on the storage account

With these three changes, your Function App will authenticate with its AzureWebJobsStorage using UAMI.

Caveat: Although this works, the issue with this approach is all services that are assigned this UAMI will gain access to the function’s storage account. This is not ideal if many services share the same UAMI. The better option will be to use System Assigned Managed Identity (SAMI) for authentication between Function App and its storage account. For the rest of the outbound calls that the functions might make, use UAMI.

Using System Assigned Managed Identity

To use SAMI just setAzureWebJobsStorage__accountName — SAMI is the default, no additional settings needed. Next, give SAMI Storage Blob Data Owner on the storage account. If you are using Terraform to deploy the authentication block of the Function App will look like this —

authentication = {
type = “systemassignedidentity”
}

SAMI is my preferred method for authentication with the AzureWebJobsStorage for the reasons already discussed in the caveat section.

Summary

Configuring a Function App to authenticate with its AzureWebJobsStorage using managed identity requires changes at three levels — Terraform, app settings, and RBAC — and all three must be consistent with each other. For UAMI, all three AzureWebJobsStorage__* settings are mandatory; omitting any one of them will cause the runtime to fail. However, personally I feel UAMI for AzureWebJobsStorage is rarely the right choice — since UAMI is a shared identity, every service assigned to it inherits access to the storage account. SAMI, which requires only AzureWebJobsStorage__accountName and a single role assignment, is the simpler and safer default for this use case.

Reference — Use User managed identity to replace connection string in”AzureWebJobsStorage” for function apps | Microsoft Community Hub

This guide outlines the process for assigning application roles to a Managed Identity (MI) in Entra ID. It covers observed behaviors, inherent limitations, and the necessary steps required when an MI must authenticate with another application (such as an API in APIM) using role-based access control (RBAC).

Scenario

In a typical architecture, a Logic App utilizes a Managed Identity (either System-Assigned or User-Assigned) to communicate with downstream resources. When that Logic App needs to call an API exposed via APIM, the following requirements usually apply:

• The API is protected by its own App Registration in Entra ID.
• The API expects the caller to possess specific app roles (e.g., API.Read or API.ReadWrite).
• The Logic App must obtain an OAuth token containing these roles to successfully authorize against the API.

The Challenge

Managed Identities are automatically created Service Principals. A common point of confusion is that they do not appear in the App Registration section of the Azure portal; they are found exclusively under Enterprise Applications.

Because the Azure portal does not currently provide a UI for assigning app roles to Enterprise Applications directly, it is not possible to assign roles like API.Read through the standard “API Permissions” blade used for traditional App Registrations.

The Workaround — Assigning App Roles via PowerShell / Microsoft Graph

You can use the below Powershell to assign roles to your Managed Identity

# Install-Module Microsoft.Graph -Scope CurrentUser (If not done already)

# Your tenant ID (in the Azure portal, under Azure Active Directory > Overview).
$tenantID = ‘{tenantId}’

# The name of the server app that exposes the app roles.
$serverApplicationName = ‘{serverApplicationName}’

# The name of the app role that the managed identity should be assigned to.
$appRoleName = ‘{appRoleName}’ # For example, Api.Read

# Look up the Logic App / Function (Client application) managed identity’s object ID.
$managedIdentityObjectId = ‘{managedIdentityObjectId}’

# Connect-MgGraph -TenantId $tenantId -Scopes ‘Application.ReadWrite.All’,‘Directory.Read.All’
# or a more restricted set of permissions (recommended):
Connect-MgGraph -TenantId $tenantId -Scopes ‘Application.Read.All’,‘AppRoleAssignment.ReadWrite.All’

# Look up the details about the server app’s service principal and app role.
$serverServicePrincipal = (Get-MgServicePrincipal -Filter “DisplayName eq ‘$serverApplicationName’”)
$serverServicePrincipalObjectId = $serverServicePrincipal.Id
$appRoleId = ($serverServicePrincipal.AppRoles | Where-Object {$_.Value -eq $appRoleName }).Id

Write-Host ‘$serverServicePrincipal ’ $serverServicePrincipal
Write-Host ‘$managedIdentityObjectId ’ $managedIdentityObjectId
Write-Host ‘$serverServicePrincipalObjectId ’ $serverServicePrincipalObjectId
Write-Host ‘AppRoleId >’ $appRoleId

# Assign the managed identity access to the app role.
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $serverServicePrincipalObjectId -PrincipalId $managedIdentityObjectId -ResourceId $serverServicePrincipalObjectId -AppRoleId $appRoleId

• PrincipalId → Managed Identity object ID (Logic App)
• ResourceId → API service principal object ID
• AppRoleId → GUID of the role defined in the API registration

After this assignment, tokens requested by the Managed Identity will include the required roles claim, allowing successful authorization against the API.

Note

• For clientId to be able to be used as an audience it must “own” App Roles. And the consumer-client-id should have been provided this roles in AAD. I think you can further check these claims in the Authentication section

Key Takeaways

• Managed Identities always appear as Enterprise Apps in Azure AD.
• App roles cannot be assigned via the portal for Enterprise Apps; Graph / PowerShell is required.
• Token validation depends on correct Issuer, Audience, and presence of role claims.
• Explicit role assignment ensures tokens carry the required roles for API authorization.

Accessing Azure App Configuration using Managed Identity in Azure Functions is slightly different from accessing other Azure services.

For most Azure services (Storage, Service Bus, Key Vault), you typically:

• Enable Managed Identity on the Function
• Grant RBAC access to the resource
• Create the SDK client using DefaultAzureCredential

However, App Configuration is usually loaded as part of the application configuration pipeline at startup, so it must be added via the host builder.

Prerequisites

• Enable Managed Identity on the Function App
• Grant the identity: App Configuration Data Reader on the App Configuration resource

Sample code as shown below

var host = new HostBuilder()
.ConfigureAppConfiguration(builder =>
{
string cs = Environment.GetEnvironmentVariable(“ConnectionString”);
builder.AddAzureAppConfiguration(options =>
options.Connect(new Uri(@“https://appconfiguri.azconfig.io”), new ManagedIdentityCredential()));
})
.ConfigureFunctionsWebApplication()
.Build();
host.Run();

Note: I’m using ManagedIdentityCredential but the recommend class is DefaultAzureCredential

Key Insight

• Other Azure services → authenticated when creating the client
• App Configuration → authenticated when building the configuration provider. That’s why it must be configured inside ConfigureAppConfiguration().