ASP.NET Core根据用户App角色返回不同结果的最佳实践

• 方案②（前端每次请求额外传递ID Token、后端手动解码校验）：不推荐。ID Token的设计用途仅为客户端侧完成用户身份核验，不属于API授权场景下的合法凭证，这种实现既违背OAuth2.0/OpenID Connect规范，额外增加前后端冗余逻辑，也和你当前接入的Microsoft.Identity.Web自动化鉴权体系完全不兼容，后续维护成本很高。
• 方案①（将角色声明写入Access Token）：这是微软官方推荐的标准实现路径，完全适配你当前的技术架构，是最简洁规范的方案，不需要改动现有认证流程的核心逻辑，仅需调整少量配置即可实现。

1. Azure AD侧配置调整 #

首先确认你创建的App Roles是挂载在后端API对应的应用注册下的：Access Token的受众是后端API，只有定义在API应用注册下的角色，才会被写入到发给前端、用于访问API的Access Token中。如果之前你把角色建在了前端客户端的应用注册下，需要同步在后端API的应用注册中创建同名同ID的角色，并重新完成用户分配。
之后给Access Token添加roles可选声明：

• 进入后端API的应用注册页面，打开Token configuration菜单
• 点击Add optional claim，令牌类型选择Access，在声明列表中勾选roles后保存
• 如果弹出提示要求开启Microsoft Graph的profile相关权限，勾选确认即可。

2. 后端代码调整 #

你现有的AddMicrosoftIdentityWebApi配置默认会自动完成Access Token的验签、声明解析，不需要手动写任何令牌解码逻辑，直接用ASP.NET Core内置的授权能力即可：

• 可以直接通过[Authorize]特性做接口级的角色拦截，示例代码：

// 仅CEO角色可访问的接口
[Authorize(Roles = "CEO")]
[HttpGet("all-records")]
public IActionResult GetAllRecords()
{
    return Ok(_dataService.GetFullList());
}

• 对于多角色可访问、需要内部做数据过滤的接口，直接通过User对象读取角色信息做分支处理即可，示例：

[Authorize(Roles = "CEO,PM")]
[HttpGet("records")]
public IActionResult GetRecords()
{
    // CEO角色返回全量数据
    if (User.IsInRole("CEO"))
    {
        return Ok(_dataService.GetFullList());
    }
    // PM角色返回仅分配给当前用户的数据子集
    var currentUserId = User.FindFirstValue(ClaimTypes.NameIdentifier);
    return Ok(_dataService.GetUserAssignedList(currentUserId));
}

你之前实现的scope校验逻辑可以完全保留，和角色校验逻辑互不冲突。

3. 前端调整 #

不需要修改任何现有认证、请求传参逻辑，前端还是按照原有流程通过MSAL获取Access Token，放在请求的Authorization头中传递给后端即可。配置生效后，MSAL新获取的Access Token会自动携带roles声明，不需要额外传递ID Token。

• 配置修改完成后，需要让当前登录用户重新登录获取新的Access Token，本地缓存的旧令牌不会自动新增roles声明。
• 前端可以读取ID Token里的角色信息做UI元素的显隐控制，但所有权限校验、数据过滤逻辑必须放在后端实现，不能依赖前端传入的角色参数做判断。

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