调用后端API：用ID Token还是Access Token？如何传递角色？

首先明确：你当前用ID Token做API授权的方式不符合Azure AD的设计规范——ID Token的核心作用是让客户端（比如前端）确认用户身份，它的受众（aud声明）是你的客户端应用ID，而非API的ID，API验证时会因为受众不匹配直接拒绝，而且ID Token并不具备授权API的设计意图。正确的做法是使用针对API的Access Token来做授权。

一、规范的端到端实现流程 #

1. 前端获取API专属的Access Token

   • 发起token请求时，必须指定目标API的应用ID URI或客户端ID作为scope，比如格式为api://{你的API应用ID}/.default。这个scope告诉Azure AD，你要获取的是针对该API的授权凭证。
   • 举个例子，用授权码流请求token时，scope参数要填api://xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx/.default openid profile（后面的openid profile是用来获取ID Token做前端身份认证的，不影响Access Token的授权用途）。

2. 后端API验证Access Token并做授权判断

   • 后端不要手动解码token，直接用官方库来处理：比如ASP.NET Core可以用Microsoft.Identity.Web，它会自动验证Access Token的签名、过期时间、受众（aud必须匹配API的应用ID）等合法性。
   • 验证通过后，从token的roles声明中提取用户角色，然后用角色授权特性（比如[Authorize(Roles = "OrderAdmin")]）或者自定义逻辑来控制接口访问权限。

二、让Access Token携带角色的配置步骤 #

你已经在服务主体配置了App roles，接下来需要完成以下关键配置：

• 确保角色定义在API的服务主体上：登录Azure AD门户，找到你的API应用（不是客户端应用），进入“应用注册”→“应用角色”，确认你配置的角色是在这里定义的（如果之前配错到客户端应用上，需要移过来）。
• 将用户/组分配到API的角色中：在Azure AD的“企业应用”里找到你的API对应的服务主体，进入“用户和组”，添加需要授权的用户或组，并为他们分配对应的App roles。
• 请求Access Token时指定正确的scope：如前面所说，必须请求API的专属scope，Azure AD才会将用户的角色注入到Access Token的roles声明里。

补充说明 #

如果你的API是多租户应用，还要确保在API的应用注册中开启“接受任何组织目录中的用户”，并且在分配角色时选择对应的租户用户。另外，使用Microsoft.Identity.Web库可以大幅简化token验证和角色提取的代码，避免手动处理带来的安全问题。

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