AspNetCore本地开发：无需Client Secret调用MSGraph的可行方案？

针对你的场景，完全可以不用引入Client Secret实现本地开发时的应用权限MS Graph调用，以下是三种可行方案：

方案1：使用应用证书作为本地凭据源 #

这是最贴近现有K8s配置的方案，用证书替代Client Secret：

1. 在Azure门户的目标应用注册中，上传一个自签名或CA颁发的证书（路径：应用注册→证书和机密→证书→上传证书）。
2. 修改本地appsettings.Development.json的凭据配置：

"AzureAd": {
  "TenantId": "<tenantId>",
  "ClientId": "<clientId>",
  "ClientCredentials": [
    {
      "SourceType": "Certificate",
      "CertificatePath": "本地证书文件路径（如./my-cert.pfx）",
      "CertificatePassword": "<证书密码（如果设置）>"
    }
  ]
}

3. 原有代码无需改动，Microsoft Identity Web会自动加载证书获取应用权限令牌，全程不涉及Client Secret。

方案2：手动集成DefaultAzureCredential（灵活适配开发者工具） #

跳过Microsoft Identity Web的默认凭据逻辑，直接用Azure.Identity的DefaultAzureCredential获取应用权限令牌，自动回退到Azure CLI、Visual Studio等开发者身份：

注意：需确保你的开发者账号已被授予目标MS Graph应用权限的管理员同意（应用权限必须由管理员批准）。

1. 修改代码注册逻辑：

// 注册DefaultAzureCredential，自动适配本地开发环境
builder.Services.AddSingleton<DefaultAzureCredential>();

// 手动注册GraphServiceClient，指定应用权限范围
builder.Services.AddSingleton<GraphServiceClient>(sp =>
{
    var credential = sp.GetRequiredService<DefaultAzureCredential>();
    // ".default"表示使用应用注册中已配置的所有应用权限
    return new GraphServiceClient(credential, new[] { "https://graph.microsoft.com/.default" });
});

// 保留原有API认证配置（如果需要API本身的身份验证）
builder.Services
    .AddAuthentication()
    .AddMicrosoftIdentityWebApi(builder.Configuration, "AzureAd");

2. 本地开发时，确保已用Azure CLI登录（az login），或在Visual Studio中登录了有权限的Azure账号，DefaultAzureCredential会自动选用合适的凭据获取令牌。

方案3：本地模拟Workload Identity（与K8s环境完全一致） #

利用Azure CLI的workload-identity扩展，在本地模拟K8s的Workload Identity环境，无需修改任何代码或配置：

1. 安装workload-identity扩展：

az extension add --name workload-identity

2. 登录Azure并设置目标订阅：

az login
az account set --subscription <你的订阅ID>

3. 关联应用注册并本地登录Workload Identity：

az workload-identity login --client-id <应用注册ClientId> --tenant-id <租户ID>

4. 直接运行本地应用，此时环境变量会被自动配置，Microsoft Identity Web会和K8s集群内一样使用Workload Identity流程获取令牌。

关于之前自定义ICredentialSourceLoader失败的原因 #

你遇到的AADSTS700019错误，是因为api://AzureADTokenExchange是Workload Identity专用的令牌交换资源，只有托管标识或Workload Identity服务账号有权请求，普通用户身份（如Azure CLI登录的账号）无法访问。而Microsoft Identity Web默认会优先尝试获取该资源的令牌进行Workload Identity交换，导致开发者凭据直接失败。

内容的提问来源于stack exchange，提问作者PeterE