基于 Amazon Bedrock AgentCore Gateway 实现多租户智能体的 OBO 令牌交换
在多租户生产环境中部署生成式 AI 智能体时，一个核心身份难题随之浮现：当智能体代表用户调用下游 API 时，调用请求携带的是谁的标识？如果使用智能体的服务身份，审计线索将完全消失，每个下游系统都必须无条件信任该智能体；而直接转发用户令牌，则会使每个下游工具变成“混淆的代理”。OAuth 2.0 Token Exchange 规范（RFC 8693）正是为此而生，而 Amazon Bedrock AgentCore Identity 将其作为原生凭证提供者授权类型加以支持。
本文是《使用 Amazon Bedrock AgentCore 构建多租户智能体》和《通过 Bedrock AgentCore Gateway 拦截器实现细粒度访问控制》的实践续篇，详细演示了针对 Okta 的完整多租户 OBO 设置，展示了 JSON Web Token（JWT）声明在每个跳转中的转换过程，并解释了受众绑定如何实现跨租户的纵深防御。
为什么需要 OBO 令牌交换？
OBO 模式在多租户场景下至关重要。以一个服务于两个租户（Acme 和 Globex）的旅行预订助手 TravelBot 为例，当用户通过智能体预订航班时，智能体需要调用不同租户的 API。如果 API 要求验证用户身份，直接使用用户原始令牌会导致“混淆代理”问题——Acme 的 API 可能误处理 Globex 用户的令牌。通过 OBO 交换，智能体可以将用户令牌转换为针对特定下游 API 的、绑定受众的新令牌，确保每次调用都经过精确授权。
OBO 在 Bedrock AgentCore 中的实现
Amazon Bedrock AgentCore Gateway 支持 OAuth 2.0 Token Exchange（RFC 8693）作为原生凭证提供者授权类型。利用这一能力，AgentCore Gateway 可以在调用下游工具之前透明地将入站用户令牌交换为新的、绑定受众的令牌，而无需智能体本身实现交换逻辑。
具体流程如下：
- 用户通过客户端应用获取 Okta 颁发的访问令牌（受众为 AgentCore Gateway）。
- AgentCore Gateway 收到请求后，识别出需要调用下游租户 API。
- Gateway 使用用户的令牌向 Okta 发起 OBO 交换请求，请求一个受众为目标 API 的新令牌。
- Okta 验证用户令牌有效且满足条件后，颁发新令牌（受众为特定 API）。
- Gateway 使用新令牌调用下游 API。
关键优势
- 身份跨租户传播：原始调用者的身份在整个调用链中保持透明，下游系统可以基于用户身份执行细粒度授权。
- 消除混淆代理问题：每个下游 API 收到的令牌都明确绑定其受众，不会误处理其他租户的请求。
- 纵深防御：通过受众绑定和令牌交换，即使某个环节被攻破，攻击者也无法重用令牌访问其他资源。
- 与现有 OAuth 2.0 基础设施集成：直接利用 Okta、Auth0 等身份提供商的能力，无需额外搭建。
实施要点
参考实现 TravelBot 展示了完整的端到端设置。关键步骤包括：
- 配置 Okta 应用程序：为 AgentCore Gateway 和每个租户 API 分别注册应用，并设置正确的受众和授权策略。
- 定义令牌交换策略：在 AgentCore Gateway 中配置凭证提供者，指定交换端点、客户端凭据和所需的声明映射。
- 设置拦截器：使用 Gateway 拦截器在运行时触发令牌交换，并将新令牌注入下游请求。
- 测试多租户场景：验证不同租户用户调用同一智能体时，下游 API 能正确识别用户身份并执行相应授权。
适用场景与限制
OBO 模式最适合多租户智能体需要调用多个下游服务且入站令牌受众与下游 API 不匹配的场景。对于单租户智能体，如果入站令牌受众已匹配下游服务，直接转发令牌可能更简单。此外，OBO 交换会增加一次网络往返，需要权衡延迟。
总结
Amazon Bedrock AgentCore Gateway 的 OBO 令牌交换能力为多租户智能体提供了一种标准、安全的身份传播方案。通过结合 Okta 等身份提供商，开发者可以构建出审计清晰、权限精细的生成式 AI 应用，同时避免常见的安全陷阱。完整的参考实现代码将在 aws-samples/sample-obo-flow-poc 仓库中发布。
