Node.js应用中DefaultAzureCredential无法获取Azure SQL访问令牌

针对你遇到的AggregateAuthenticationError和CredentialUnavailableError，可以从以下几个方向逐步排查：

1. 验证托管标识的基础配置 #

• 确认App Service已启用用户分配的托管标识，且AZURE_DEV_MI_CLIENT_ID环境变量的值是该标识的Client ID（不是Object ID或资源ID），可在Azure门户的托管标识详情页找到Client ID。
• 确保该托管标识已被授予Azure SQL的访问权限：
  • 若需访问整个SQL Server，可在SQL Server的「Azure Active Directory」设置中，将该标识设置为Azure AD管理员。
  • 若仅需访问特定数据库，需在目标数据库中执行SQL命令创建用户并授权：

    CREATE USER [你的托管标识名称] FROM EXTERNAL PROVIDER;
    ALTER ROLE db_datareader ADD MEMBER [你的托管标识名称];
    ALTER ROLE db_datawriter ADD MEMBER [你的托管标识名称];
    

2. 简化Credential配置，排除链上干扰 #

DefaultAzureCredential会尝试多种认证方式，可能掩盖具体问题。直接使用ManagedIdentityCredential仅针对用户分配标识认证，缩小排查范围：

const { Connection, Request } = require("tedious");
const { ManagedIdentityCredential } = require("@azure/identity");

// 直接使用ManagedIdentityCredential指定用户分配标识
const credential = new ManagedIdentityCredential({ 
  clientId: process.env.AZURE_DEV_MI_CLIENT_ID 
});

async function getAccessToken() {
  try {
    const accessToken = await credential.getToken("https://database.windows.net/.default");
    console.log('获取到的令牌:', accessToken.token);
  } catch(err){
    console.error('认证错误详情:', err);
  }
}
getAccessToken();

3. 确认环境变量生效 #

• 在App Service的「配置」->「应用程序设置」中，检查AZURE_DEV_MI_CLIENT_ID是否已正确添加，且已重启App Service让环境变量生效。
• 在代码中添加日志打印process.env.AZURE_DEV_MI_CLIENT_ID，确认该值与托管标识的Client ID完全一致。

4. 检查网络与权限策略 #

• 确认App Service可以访问Azure SQL：
  • 若App Service使用VNet集成，需确保VNet已配置SQL Server的入站网络规则。
  • 若为公共访问，需在SQL Server的防火墙设置中允许Azure服务访问，或添加App Service的出站IP到防火墙白名单。
• 检查Azure AD的条件访问策略，确认没有阻止该托管标识获取令牌的规则。

5. 通过CLI验证标识可用性 #

使用Azure CLI直接测试托管标识能否获取令牌，排除代码层面问题：

# 以用户分配标识登录
az login --identity -u <你的托管标识Client ID>
# 获取Azure SQL的访问令牌
az account get-access-token --resource https://database.windows.net

如果CLI能成功获取令牌，说明标识本身配置正常，问题出在代码或App Service的环境配置上；如果CLI也失败，需检查托管标识的权限和状态。

内容的提问来源于stack exchange，提问作者Mr. K