Azure AD中Group、Role、Scope的区别及Web API权限配置疑问

现有方案错漏说明 #

你当前规划的「创建权限分组→定义应用角色→角色绑定分组」的配置逻辑完全符合Azure AD权限管控的最佳实践，没有原则性错漏。唯一需要注意的是：代码侧做权限校验时建议直接校验角色，而非校验用户所属的组，避免后续分组规则调整时要修改业务代码。

问题解答 #

1. 已经可以通过Group管理访问权限的场景下，Role的作用是什么？ #

Role的核心价值是实现权限逻辑和身份组织架构的解耦，具体作用包括：

• 降低业务代码耦合：Group本质是用户的组织分类载体，Role才是API层面的权限定义载体。代码中只需要判断请求方是否持有对应角色即可，不用关心角色是直接分配给用户、还是分配给用户所在的组，后续调整权限分配规则无需修改代码。
• 覆盖非用户身份的权限场景：如果后续有服务主体（后台应用、自动化脚本）需要访问你的API，无法将服务主体加入用户组，但可以直接给服务主体分配应用角色。
• 支持API能力标准化：应用角色是注册在Web API的Azure AD应用实体下的，属于API本身的公开能力定义，如果你后续需要把API开放给其他租户使用，对方可以直接看到你定义的角色，不需要理解你内部的分组规则。

2. 哪些场景下需要同时使用Role与Group来管理访问权限？ #

以下场景推荐同时使用两者：

• 大规模企业级权限运维：不需要给每个用户逐个分配角色，只需要把角色绑定到对应组，用户入组自动获得权限、出组自动回收权限，大幅降低运维成本。
• 多维度权限管控场景：如果需要同时管控操作权限和数据范围，比如不同部门的用户只能访问本部门的数据，可以用Group区分用户所属部门，用Role区分读写操作权限，代码同时校验两个维度的身份信息即可实现细粒度管控。
• 多应用权限复用场景：如果企业内部有多个API都需要区分读写权限，可以复用同一套用户分组，给不同API的角色分别绑定同一个分组，不需要为每个API单独维护分组规则。

3. Azure AD中的Scope是什么，有什么作用？ #

Scope是基于OAuth2.0协议定义的委托访问权限，和应用角色的核心区别是适用场景不同：

• Scope针对委托访问场景：也就是第三方客户端应用代表登录用户访问你的API时，Scope用于限制这个客户端应用能代表用户操作的范围。比如用户本身有读写权限，但第三方客户端只申请了读Scope，那么该客户端只能调用读接口，无法调用写接口。
• Scope支持用户级授权：我们平时使用第三方应用时弹出的「允许该应用读取你的个人信息」提示，就是用户在给第三方应用授予对应的Scope权限。
• 简单区分规则：角色用于规定「谁（用户/服务主体）能执行什么操作」，Scope用于规定「哪个客户端应用能代表用户执行什么操作」。

三者核心区别总结 #

• Group：用户/服务主体的集合容器，用于批量管理身份，本身不定义权限，只是权限分配的载体。
• Role：API侧定义的操作权限等级，支持分配给用户、组、服务主体，适用于用户直接访问API、服务主体访问API的场景，是代码侧权限校验的核心依据。
• Scope：OAuth2.0框架下的委托访问权限限制，用于约束第三方客户端代表用户访问API的权限范围，适用于客户端应用调用API的场景。

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