如何为.NET 7 API配置Azure AD登录？现有方案是否合规？

当前方案虽然看似能运行，但核心逻辑存在问题，以下是具体分析和修正方案：

核心问题分析 #

1. 令牌受众不匹配
   你获取的令牌受众是Microsoft Graph API（00000002-0000-0000-c000-000000000000），但你的API却将其作为自身的验证受众。这类令牌是Azure AD颁发给Graph API使用的，并非给你的API的。虽然当前验证通过是因为令牌包含你的应用ID，但这属于“误用”，后续Azure AD的验证逻辑更新可能导致API无法正常验证令牌。

2. 权限配置冗余且不合理
   你在应用中添加了Microsoft Graph的email权限，但你的流程并未实际调用Graph API。企业租户对Graph权限的敏感度通常更高，反而可能增加用户授权的阻力——而你真正需要的只是用户的身份信息（邮箱、ID），完全可以通过OpenID Connect的基础范围实现，无需依赖Graph API权限。

3. 授权请求范围缺失
   前端授权请求仅指定offline_access范围，缺少OpenID Connect必需的openid范围，这不符合OIDC规范。正确的身份验证需要openid来触发ID令牌的颁发，搭配profile、email获取用户基本信息。

正确实现方案 #

针对你的需求（仅验证用户身份、获取邮箱/ID匹配数据库），最佳实践是使用OpenID Connect身份验证流，无需依赖Graph API权限：

1. Azure AD应用注册调整 #

• 无需添加Microsoft Graph API权限，仅保留默认的OpenID Connect权限（openid、profile、email）。
• 确保应用注册的“支持的账户类型”设为“任何组织目录中的账户”（对应organizations租户ID）。
• 若前端是单页应用，启用“ID令牌”颁发；若为Web应用，确保重定向URI配置正确。

2. 前端授权请求修正 #

使用v2.0端点（更现代、兼容更广），指定完整的OIDC范围：

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=[MyApi.ClientId]&redirect_uri=[FrontendRedirectUri]&response_type=code&prompt=consent&scope=openid%20profile%20email%20offline_access&response_mode=query

3. 令牌交换与API验证 #

• 调用https://login.microsoftonline.com/common/oauth2/v2.0/token端点交换授权码时，保持scope为openid profile email offline_access，将获取到的ID令牌（包含用户邮箱、ID等声明）传递给API。
• 修正API的Azure AD配置，将Audience设为你的应用ClientId（而非Graph API的ID）：

IConfigurationSection azureAdSection = _configuration.GetSection("AzureAd");
azureAdSection.GetSection("Instance").Value = "https://login.microsoftonline.com/";
azureAdSection.GetSection("Audience").Value = MyApi.ClientId; // 改为自身应用ID
azureAdSection.GetSection("ClientId").Value = MyApi.ClientId;
azureAdSection.GetSection("ClientSecret").Value = MyApi.ClientSecret;
azureAdSection.GetSection("TenantId").Value = "organizations";
services.AddMicrosoftIdentityWebApiAuthentication(_configuration, "AzureAd");

4. 企业租户友好性说明 #

使用OpenID Connect的基础范围（openid、profile、email）属于Azure AD的默认允许范围，大多数企业租户无需管理员额外同意即可让用户授权，完美匹配你的目标受众需求。

关于之前的AADSTS650052错误 #

你尝试使用第二个应用时触发的错误，是因为该应用的服务主体未在目标企业租户中创建（需要管理员同意才能创建）。而当前误用Graph API受众的方案能绕过这个问题，是因为Graph API的服务主体在所有企业租户中默认存在，但这并非合规的解决方式。

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