基于Microsoft EntraID的多API调用链用户上下文保留方案咨询

1. Microsoft OBO（On-Behalf-Of）流 #

实现逻辑 #

B作为中间层，使用用户从A传来的ID/访问令牌，向Entra ID请求代表该用户调用C的专用令牌；同理，C再用此OBO令牌请求调用D的令牌，全程保留用户身份与授权上下文。

已知缓存问题补充 #

OBO令牌是绑定特定下游API（aud字段）和用户的，每个用户、每个下游服务的令牌无法复用，会导致Entra ID的令牌请求量激增，高并发场景下可能触发限流。

其他弊端 #

• 链路复杂度飙升：B、C都要集成OBO流的令牌交换、刷新、错误处理逻辑，代码维护成本大幅增加。
• 权限链强依赖：用户必须直接拥有调用D的权限（或通过Entra ID应用角色映射），若D权限独立于B/C，需额外配置权限映射，容易出现配置失误。
• 性能损耗明显：每次跨服务调用都要做一次令牌交换，增加网络延迟，成为高并发场景的潜在瓶颈。

2. Token Forwarding（令牌转发） #

实现逻辑 #

将A传给B的用户访问令牌直接转发给C，再由C转发给D，所有服务均用该用户令牌完成授权验证。

核心顾虑的解决方向 #

若B、C不是原始令牌的aud受众，可通过两种方式处理：

• 在Entra ID中配置B、C为该用户令牌的允许受众，或开启跨应用验证权限；
• 自定义令牌校验逻辑：B/C放宽aud校验，重点验证令牌签名、过期时间及用户角色是否符合自身服务要求（此方式会降低安全性，需谨慎使用）。

权衡点 #

• 优势：实现简单，无额外令牌交换开销，完全保留用户上下文。
• 劣势：
  • 令牌泄露风险高：原始用户令牌可能包含多服务权限，一旦泄露，攻击者可访问所有授权服务；
  • 生命周期限制：用户令牌有效期通常较短（默认1小时），长耗时操作中易过期，需额外处理刷新逻辑；
  • 权限粒度适配难：若B、C、D需不同权限粒度，原始令牌要么权限过大，要么无法满足需求。

3. 用户上下文传递+独立服务授权 #

实现逻辑 #

• B层从用户令牌中提取核心信息（如用户ID、角色、租户ID），通过自定义请求头（如X-User-ID、X-User-Roles）传递给C、D；
• B、C仍用client credentials流调用下游，但D需结合传递的用户上下文与自身权限系统（或Entra ID RBAC）完成授权。

权衡点 #

• 优势：避开令牌转发的安全风险，无需OBO的令牌交换开销；各服务授权逻辑独立，B/C用自身服务身份调用，D专注于用户上下文授权。
• 劣势：
  • 上下文可信度低：自定义头传递的信息易被篡改，需B/C对信息进行签名（如JWT签名），增加校验复杂度；
  • 权限同步滞后：若用户权限在请求过程中变更（如角色被撤销），D无法实时感知，需依赖权限系统缓存或实时查询。

4. 自定义会话令牌+集中式授权服务 #

实现逻辑 #

• B层收到用户令牌后，生成包含用户ID、权限范围、有效期的自定义会话令牌，签名后传递给C、D；
• 部署集中式授权服务，C、D收到会话令牌后，先调用授权服务验证有效性与权限，再处理业务请求。

权衡点 #

• 优势：可自定义令牌的权限粒度与生命周期，适配不同服务需求；集中式授权便于统一管理规则，降低各服务授权逻辑复杂度。
• 劣势：需额外开发维护集中式授权服务，增加系统架构复杂度；每次请求都要调用授权服务，存在网络延迟与单点故障风险。

5. 分布式追踪上下文关联 #

实现逻辑 #

• A层生成包含用户ID的追踪上下文，通过标准追踪头（如traceparent）传递给B、C、D；
• D处理请求时，通过追踪ID关联用户上下文（需从追踪系统或日志存储中查询），再结合自身权限系统完成授权。

权衡点 #

• 优势：不依赖令牌传递，避免令牌安全风险；追踪上下文可同时用于监控排查，一举两得。
• 劣势：需集成分布式追踪系统，增加系统复杂度；D需额外逻辑关联追踪ID与用户信息，存在性能损耗；无法直接从追踪上下文获取权限，需依赖外部存储查询。

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