ServiceNow 与 Bedrock AgentCore Gateway 的代表用户令牌交换集成

AgentCore Gateway 的一项具体变化，是在目标配置中直接支持 OBO（代表用户调用）令牌交换。用户从 Microsoft Entra ID 取得面向 AI 应用的 JWT，代理调用网关后，网关会使用代理应用的客户端凭据，将该令牌换成面向 ServiceNow API 连接器的新令牌，无需再通过 Lambda 拦截器编写交换逻辑。Entra ID 在验证委托权限后签发新令牌，ServiceNow 再依据 preferred_username 等声明定位用户，并按该用户权限处理请求。

配置重点

整体配置分为 Entra ID、ServiceNow 和 AgentCore Gateway 三部分：

• Entra ID：创建两个应用注册。一个代表 ServiceNow API 连接器，并公开 user_impersonation 范围；另一个代表 AI 代理，需要配置客户端机密、对 API 连接器的 API 权限以及用户委托同意。
• ServiceNow：创建入站 OAuth 集成，选择第三方 OIDC 令牌模式，填写 API 连接器的客户端 ID 和租户 OIDC 元数据地址。将用户声明映射到对应字段，例如把 preferred_username 映射到 Email；认证范围应限制为 Table API 等实际使用的接口。
• AgentCore Gateway 出站认证：创建自定义 OAuth 客户端，填写代理应用的客户端 ID、客户端机密和 Entra 发现地址，并选择 JWT authorization grant。网关的入站身份则使用代理应用的身份提供方配置。
• 目标与令牌交换：通过内联 OpenAPI 定义 ServiceNow 目标，选择已创建的出站 OAuth 配置和 Token exchange grant。请求范围设为 api://<API连接器客户端ID>/user_impersonation，同时加入自定义参数 requested_token_use:on_behalf_of。缺少该参数时，Entra ID 不会按 OBO 流程完成交换。

适用场景

这一模式适合由 AI 代理代表用户查询事件、更新工单或调用其他企业 REST API 的场景。其重点不是替用户扩大权限，而是把现有用户身份完整传到下游，使审计记录、最小权限和 ServiceNow 的用户级访问控制继续有效。采用相同思路时，其他 OAuth 保护型 API 也可适配，但令牌受众、权限范围和用户声明必须逐项核对。

限制与排查

• 原生 OBO 要求网关使用 MCP 版本 2025-11-25；较早版本创建的网关不能直接启用该能力。
• Entra ID 必须已授予相应委托权限。出现认证错误时，应检查代理应用的 API 权限、ServiceNow 认证范围，以及声明所映射的邮箱是否对应有效用户。
• 若令牌不包含 JTI，可按租户配置清除 ServiceNow 的 JTI 验证；也可将 Entra 的 uti 映射为 jti，以利用其重放防护和拒绝列表能力。
• 身份传播与内容安全是两类控制。生产环境可另行结合 Amazon Bedrock Guardrails 过滤有害内容、检查代理输入输出，但它不能替代 OBO 身份传递。

测试结束后，应删除不再使用的网关、目标、出站认证配置及临时创建的云端和 ServiceNow 资源。上述版本要求与配置路径按 2026 年 11 月 3 日的资料整理，正式部署前仍需核对最新产品文档。

资料来源：ServiceNow on-behalf-of token exchange with Bedrock AgentCore Gateway（2026-11-03）。