企业授权验证方法 - EntraID On-Behalf-Flow的简单用法

知识点： EntraID 支持多少种授权方式？

1. 基于角色的访问控制（RBAC, Role-Based Access Control） • 通过 内置角色（例如全局管理员、用户管理员、应用管理员等）或者 自定义角色 来控制用户/组/应用对资源的访问权限。 • 常用于管理 Azure 资源、Entra ID 本身的管理权限。
2. 基于组的授权（Group-based Authorisation） • 把用户分配到安全组或 Microsoft 365 组，然后将组赋权给应用或资源。 • 应用可以通过 Graph API 获取用户的组成员身份，从而进行授权。
3. 基于应用的授权（Application Permissions & Delegated Permissions） • 在 OAuth 2.0 / OpenID Connect 场景下： • Delegated permissions：代表登录的用户访问资源（应用获得用户的同意）。 • Application permissions：应用本身（守护进程/后台服务）直接访问资源，不依赖用户登录。
4. 条件式访问（Conditional Access）授权控制 • 基于条件（用户组、设备状态、网络位置、风险等级等）决定是否允许访问。 • 本质是 访问控制策略，属于更细粒度的授权手段。
5. 基于声明（Claims-based Authorisation） • 应用通过解析 ID Token / Access Token 里的 claims（例如 roles、groups、scp 等）来判断是否允许用户访问某些功能。 • 常用于自定义应用的细粒度访问控制。
6. 基于策略的访问控制（ABAC, Attribute-Based Access Control） • 通过 自定义安全属性（Custom Security Attributes） 或资源标签，结合条件访问与 RBAC，形成更灵活的策略控制。 • 这是 Entra ID 新增的功能，用来补充 RBAC 的不足。

开始 - 场景

用户在web A上登录，为了完成某个工作，web A需要调用中间层B，中间层B调用远端服务层C，执行完后，返回结果给用户。

分析问题

1. 这是一个用户身份和权限延伸到C的问题。
2. 怎么让用户授权传递到C，而不被他人冒充身份？
3. 对于C来说，有两种情况，对应两种解决方案：
   • C不关心具体用户，只关心B是否有调用权限。 -- Application Permission + Delegation模式
   • 或者，C关心具体用户，也关心B是否具备调用权限。 -- ** On-behalf-of-flow (OBO) 用户委托模式**

构架图

Application Permission + Delegation模式

** On-behalf-of-flow (OBO) 用户委托模式**