Azure MCP Server - AZURE_TOKEN_CREDENTIALS environment variable not respected -ManagedIdentityCredential never attempted.

Question

https://github.com/microsoft/mcp/issues/1030


# AZURE_TOKEN_CREDENTIALS environment variable not respected - ManagedIdentityCredential never attempted

## Summary

The `AZURE_TOKEN_CREDENTIALS` environment variable (introduced in PR #56) is not being respected at runtime. Despite setting `AZURE_TOKEN_CREDENTIALS="prod"` or `AZURE_TOKEN_CREDENTIALS="ManagedIdentityCredential"`, the credential chain always falls through to `InteractiveBrowserCredential`, which fails in server environments (Azure Web App, Function Apps, Container Apps).

This prevents the use of Managed Identity authentication in production Azure hosting environments, which is a critical blocker for enterprise deployments.

## Environment

- **Package**: `@azure/mcp@1.0.0` (published October 30, 2025)
- **Platform**: Azure Web App for Linux (Node.js 20 LTS)
- **Managed Identity**: User-Assigned Managed Identity configured and assigned to Web App
- **Permissions**: Database Admin role on Azure Data Explorer cluster (verified working with other apps)
- **Runtime**: Node.js spawning MCP server via `npx -y @azure/mcp@1 server start --namespace kusto --read-only`

## Expected Behavior

According to PR #56 documentation and code (lines 18-24 of `CustomChainedCredential.cs`):

```csharp
/// The credential chain behavior can be controlled via the AZURE_TOKEN_CREDENTIALS environment variable:
/// - "dev": Visual Studio → Visual Studio Code → Azure CLI → Azure PowerShell → Azure Developer CLI
/// - "prod": Environment → Workload Identity → Managed Identity
/// - Specific credential name (e.g., "AzureCliCredential"): Only that credential

When AZURE_TOKEN_CREDENTIALS="prod" is set, the credential chain should be:

1. EnvironmentCredential
2. WorkloadIdentityCredential
3. ManagedIdentityCredential Should be included

When AZURE_TOKEN_CREDENTIALS="ManagedIdentityCredential" is set, only ManagedIdentityCredential should be attempted.

Actual Behavior

The credential chain always ignores the AZURE_TOKEN_CREDENTIALS environment variable and falls through to InteractiveBrowserCredential:

Error: The ChainedTokenCredential failed due to an unhandled exception: 
InteractiveBrowserCredential authentication failed: Persistence check failed.

The error message suggests that ManagedIdentityCredential and WorkloadIdentityCredential were never attempted, as the chain fell all the way to the interactive browser credential (which cannot work in server environments without a GUI).

Critical Finding: Works Locally, Fails in Azure

• Local environment (with az login): WORKS - Uses AzureCliCredential from "dev" chain
• Azure Web App (with Managed Identity + AZURE_TOKEN_CREDENTIALS="prod"): FAILS "prod" chain not activated, falls to InteractiveBrowserCredential

This proves:

1. The MCP server and code implementation work correctly
2. The "dev" credential chain (including AzureCliCredential) functions properly
3. The "prod" credential chain (Environment → WorkloadIdentity → ManagedIdentity) is not being activated despite AZURE_TOKEN_CREDENTIALS="prod" being set
4. The environment variable is either not being read or not being respected by the .NET runtime in Azure Web App

Steps to Reproduce

1. Setup Azure Resources

# Create User-Assigned Managed Identity
az identity create --name myapp-mi --resource-group my-rg

# Create Azure Web App with Node.js 20
az webapp create --name myapp --resource-group my-rg --plan myplan --runtime "NODE:20-lts"

# Assign Managed Identity to Web App
az webapp identity assign --name myapp --resource-group my-rg \
  --identities /subscriptions/{sub-id}/resourcegroups/my-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myapp-mi

# Grant permissions to Azure Data Explorer (or any Azure resource)

2. Configure Environment Variables

az webapp config appsettings set --name myapp --resource-group my-rg --settings \
  AZURE_CLIENT_ID="

Answer 1

Hello Ting Wei Lim,

Interactive Browser credential is the standard default fallback.

As discussed offline, Azure MCP server team is working on the issue and they will push the fix by this week.

https://github.com/microsoft/mcp/issues/1030

If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.