Azure B2C不支持OBO时，Web API间安全传递用户身份的方案

Azure B2C不支持on behalf of（OBO）流程，在Web应用调用Web API 1后，无法生成带有用户claims的令牌供Web API 2使用。且此时无法与客户端交互，需静默处理令牌获取/过期逻辑，最终目标是向下游传递用户claims并确保其未被篡改。

我尝试过以下方案，但均存在缺陷：

• 在客户端生成所有令牌并向下传递
  • 问题：客户端无需知晓下游服务逻辑，耦合性过高
• 向下游传递refresh token以生成新令牌
  • 问题：refresh token敏感度极高，传递过程中泄露风险大
• 放弃Azure B2C，改用自定义身份逻辑
  • 问题：需维护大量自定义代码，失去Azure基础设施的安全保障

1. 由Web API 1签发自签名JWT传递用户Claims #

Web API 1在验证用户的B2C访问令牌有效性后，使用自身的RSA密钥对签发一个包含核心用户claims（如sub、roles等）的JWT令牌，传递给Web API 2。Web API 2通过预配置的Web API 1公钥验证令牌签名，确认用户身份及claims完整性。

• 优势：无需依赖B2C的OBO能力，完全基于标准JWT机制保证安全，实现简单
• 注意事项：
  • 需在Azure Key Vault中存储Web API 1的签名密钥，避免硬编码
  • 合理设置JWT的过期时间（如15-30分钟），降低令牌泄露风险
  • Web API 2需定期同步Web API 1的公钥，或使用JWKS端点自动获取

2. 使用Azure AD B2C自定义策略生成委托令牌 #

通过Azure B2C自定义策略扩展流程，在用户完成认证后，除了颁发给Web应用的令牌外，额外生成一个可用于Web API间传递的委托令牌。Web API 1验证该委托令牌后，直接传递给Web API 2，Web API 2通过B2C的公钥验证令牌有效性。

• 优势：完全基于Azure B2C基础设施，无需额外维护令牌服务
• 注意事项：
  • 需具备B2C自定义策略的配置能力，学习成本较高
  • 需确保委托令牌的受众（aud）仅包含下游Web API，避免令牌被滥用

3. 加密传递用户Claims子集 #

Web API 1验证B2C令牌后，提取必要的用户claims，使用Azure Key Vault中的对称加密密钥对其进行加密，将加密后的字符串作为请求头或参数传递给Web API 2。Web API 2从Key Vault获取密钥解密，还原用户claims。

• 优势：无需传递任何令牌，仅传递加密后的核心信息，泄露风险极低
• 注意事项：
  • 需为Web API 1和Web API 2配置Key Vault的访问权限（使用托管身份）
  • 加密算法选择AES-GCM等带完整性验证的标准算法，确保claims未被篡改

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