在自有API中传递id_token是否可行？Blazor WASM Entra ID场景

结论：技术上可行，但不推荐，优先修复access_token问题 #

一、直接传递id_token的可行性 #

• 由于你同时控制SPA和API，只要API能正确完成id_token的验证逻辑，就能解析出其中的app_roles和自定义属性：
  • API需要验证id_token的签名、发行人（iss）、受众（aud，此处为SPA的应用ID）、过期时间等核心字段。
  • 可以通过Microsoft Identity Web库快速配置验证规则，比如指定ValidAudience为SPA的应用ID，ValidIssuer为你的Entra ID租户发行地址（如https://login.microsoftonline.com/{tenantId}/v2.0）。

二、该方案的潜在风险 #

• id_token的设计定位是供客户端（SPA）验证用户身份，而非用于API访问授权，不符合OAuth2/OIDC的最佳实践，后续扩展可能出现逻辑混乱（比如接入新客户端、API调用第三方服务时）。
• id_token不包含API专属的权限范围（scopes），若后续API需要基于细粒度scope做授权，该方案无法满足。
• 若Entra ID后续调整token格式，id_token的兼容性可能不如专门为API生成的access_token。

三、推荐的正确修复方案（解决access_token的aud问题） #

问题根源是你请求access_token时目标受众指向了MS Graph，而非自有API，调整配置即可解决：

• 在Blazor WASM的Program.cs中，配置AddMsalAuthentication时，将ApiScopes指定为自有API的暴露范围，例如：

  builder.Services.AddMsalAuthentication(options =>
  {
      builder.Configuration.Bind("AzureAd", options.ProviderOptions.Authentication);
      options.ProviderOptions.DefaultAccessTokenScopes.Add("api://{你的API应用ID}/access_as_user");
  });
  

• 确保API的应用注册中已暴露上述scope，且SPA的应用注册已获得该scope的权限（管理员或用户同意）。
• 调整后获取的access_token的aud会是API的应用ID URI，同时会携带app_roles（用户需已分配对应角色）和自定义属性（需在API应用注册中配置可选声明或通过令牌扩展添加）。

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