切换深色模式
AWS AgentCore Identity：入站身份与出站凭证
核对日期：2026-10-05。范围与 Google 篇 一致。本系统只做认证，项目负责业务授权。 本文区分 AWS 官方机制与本系统设计；没有创建 AWS 资源或进行真实调用。
1. 结论：分清入口、Agent 身份与目标资源凭证
AgentCore 将工作负载身份与凭证管理结合：调用者进入 Runtime，Agent 使用自己的工作负载身份，再获取调用下游所需凭证。这三段不是同一个 Token。Runtime 认证、凭证获取
对本系统最值得借鉴的是分段验证和用户绑定。若只需要给内部项目输出身份，凭证保险库属于可选扩展，不必纳入认证 MVP。
2. 官方机制与证据范围
| 对象 | 证明或用途 | 不应推导的结论 |
|---|---|---|
| IAM / SigV4 | 持有相应 AWS 调用凭证 | 调用代码一定来自公司 |
| 入站 JWT | 配置身份源下的调用主体 | 自动识别本地程序来源 |
| Workload identity | Agent 的逻辑工作负载主体 | 每个进程有独立身份 |
| WAT | AgentCore 第一方服务的工作负载访问凭证 | 可作为任意项目的通用 bearer |
| 下游 OAuth/API Key | 对应资源的调用凭证 | 可跨资源复用 |
WAT 是 AWS 签发的不透明令牌，只用于 AgentCore 第一方服务。托管 Runtime/Gateway 自动供给它；服务管理的身份不能按普通自建身份的方式直接领取 WAT。WAT 文档
3. 架构
以下为本系统集成设计：
图：使用 imagegen 生成。蓝色表示厂商能力，青色表示本系统集成设计；凭证交换与检查顺序以下文为准。
最后一条自有项目路径独立实现；不能把 WAT 接到项目验签器就声称完成 AWS 身份集成。
4. 本地 Agent 接入
本系统设计：本地 Agent 通过公共客户端的浏览器授权码和 PKCE 登录。Broker 将已验证 issuer + subject 映射为用户；需要访问 Runtime 时，使用为该入口配置的 audience 对应凭证。
不把用户密码交给 Agent，不将 AWS 长期密钥埋入桌面软件。不支持预期登录流程的 IdP 应更换或增加 Broker，不能照搬演示脚本中的密码登录作为生产接入。
本地实例可另登记公钥并完成持钥验证；只有相应链路明确支持并验证绑定证明时才能宣称令牌防复制。普通 JWT 登录仍应按 bearer 评估，来源默认未验证。
5. Runtime 与自建沙箱的接法
Runtime 入口可以使用 IAM 或 JWT；部署配置要明确采用哪一种。JWT authorizer 的官方字段包括 discoveryUrl、allowedAudiences、allowedClients 等。IAM 入口若传入用户 ID，还涉及 InvokeAgentRuntimeForUser 等调用权限。S1
本系统建议：面向已登录用户优先 JWT；后台服务用 IAM 并保留工作负载主体。自建沙箱采用临时角色凭证，按工作负载拆分身份和允许调用的服务范围。受托管身份供给的 Runtime，不重复套用手工获取 WAT 的流程。
用户字符串不是登录证明
GetWorkloadAccessTokenForJWT 验证用户 JWT；GetWorkloadAccessTokenForUserId 则依赖调用方提供可信用户字符串，平台不验证该字符串属于当前最终用户。S3
因此本系统只允许可信服务端从认证上下文派生 userId。不能把 HTTP JSON 中的 userId 原样传给该 API。需要兼容多个 IdP 时，用内部唯一映射或有明确边界的组合编码，避免同名用户碰撞。
6. 配置与适配器实现
下面是本系统配置，不是 AWS API 请求：
json
{
"provider": "aws-agentcore",
"region": "<selected-region>",
"runtime_id": "<runtime-id>",
"inbound_mode": "jwt",
"expected_issuer": "https://id.example.com/",
"runtime_audience": "urn:company:agent-runtime",
"user_binding_mode": "verified-jwt",
"accept_wat_at_project_api": false,
"project_audience": "urn:company:project:demo"
}部署清单：确认地区支持、配置 IdP/JWKS 和限定受众、创建 Runtime 并记录其身份、限定执行角色、配置目标凭证提供商（确有出站需求时）、部署用户会话回调。不要为了快速跑通给所有工作负载开放所有凭证提供商。
若使用三方 OAuth，AWS 要求将授权发起人与完成授权时的应用用户会话绑定；成功匹配后才完成 CompleteResourceTokenAuth。本地开发 CLI 代办部分流程不表示线上 Runtime 已替应用部署回调。会话绑定
7. 项目边界、撤销和审计
本系统负责验签、受众、时间、用户与工作负载关联；项目负责资源权限。若 Broker 自签内部凭证，必须基于自己验证的入站身份，不能仅由 Agent 声称“已取得 WAT”触发签发。
审计记录调用角色、已验证用户、工作负载、会话、目标资源与成功/失败原因。用户撤销后分别处理本系统会话、AWS 端凭证关联与目标资源授权；这些生命周期不能假设天然同步。日志和异常中不输出 Token/API Key。
8. 实施顺序与真实环境验收
先跑通 JWT Runtime 单用户调用，再验证工作负载隔离；确需三方资源时才加入保险库和回调。以下均为未实测：
| 编号 | 验收动作 | 必须看到的结果 |
|---|---|---|
| A1 | 正常 JWT 调用及错误 audience | 正常成功，错误受众拒绝 |
| A2 | 客户端修改 userId 为他人 | 不得影响服务端用户绑定 |
| A3 | 向项目提交 WAT | 拒绝其作为通用项目凭证 |
| A4 | 将 OAuth 链接转发给另一用户 | 会话不匹配不能完成绑定 |
| A5 | 跨工作负载读取已存凭证 | 按隔离要求拒绝 |
| A6 | 撤销/轮换后重试 | 测得失效窗口，没有长期旧凭证回退 |
9. 详细设计：Runtime、保险库与项目怎样衔接
本节采用员工使用 Agent 汇总工单，并可选读取第三方日历的例子。工单项目只接收内部身份；日历使用其资源方 OAuth。下面的服务接口和缓存规则均为本系统设计，AWS 官方 Token 用途见 S1—S4。
9.1 将三条会话拆开
| 会话 | 所有者 | 用途 | 生命周期终点 |
|---|---|---|---|
| 用户登录会话 | 本系统 Broker | 识别当前员工 | 登出、撤销、到期 |
| Runtime 调用上下文 | AWS 与 Agent 服务 | 识别调用者及工作负载 | 调用完成或对应凭证到期 |
| 三方 OAuth 关联 | 凭证服务与目标资源 | Agent 访问该用户的三方数据 | 用户取消关联或资源方撤销 |
不能把第一条会话登出简单描述为第三方 refresh token 已被资源方吊销。接口和界面应分别提供“退出当前会话”和“解除外部账号关联”。
9.2 受托管 Runtime 的请求时序
- 本地客户端打开浏览器登录。本系统取得用户事实，按 Runtime 配置的受众获取或签发该入口接受的 JWT。
- Runtime 在入口执行其验证。部署检查要覆盖 issuer、受众和所选客户端约束，不能只测试“带任意 JWT 能否进入”。
- Agent 接收当前调用上下文和由平台提供的 WAT，按 SDK 契约使用它。外部请求伪造的同名头不得覆盖平台注入上下文。
- Agent 需要三方数据时通过凭证提供商取得相应凭证；首次需用户参与的流程跳到受控授权页面。
- 回调服务验证当前浏览器登录会话和本次授权事务的关联，再完成会话绑定。不能仅依据回调 URL 的用户字符串确认。
- Agent 使用日历资源 Token 调用日历 API；工单项目另走本系统的身份凭证路径。两个目标的凭证与缓存隔离。
如果暂时不需要日历，省略第 4、5 步；不要把第三方同意变成用户进入工单 Agent 的强制前提。
9.3 自建沙箱的请求时序
本系统设计：沙箱启动时取得受限的临时 AWS 角色凭证，并定位预先登记的工作负载。用户请求到达可信入口后先验证用户，再调用适用的 WAT 获取路径。未验证用户时只允许按自主工作负载模式处理，不填写一个猜测的用户。
这里的 IAM 角色与工作负载登记是不同对象：角色决定调用哪些 AWS API，工作负载记录提供 Agent 层面的关联。若多份 Agent 共用一个运行角色，需要进一步限制其可代表的工作负载，不能单靠名称约定隔离。
9.4 Broker 如何给内部项目签发身份
建议采用独立入口：POST /v1/workload-sessions 接收本系统支持验证的工作负载证据；用户委托通过此前建立的一次性绑定事务关联。适配器返回内部认证上下文，再由统一签发器输出项目凭证。此接口是本系统设计，不是 AWS API。
| 检查 | 来源 | 失败行为 |
|---|---|---|
| 工作负载是否可信 | 已配置平台验证器及登记表 | 不创建会话 |
| 用户是否真实 | 已验证登录会话或可信 IdP JWT | 不接受客户端 userId |
| 用户与任务是否有关联 | 单次票据，绑定工作负载/任务/受众 | 拒绝重放或跨任务使用 |
| 项目是否为已登记目标 | 项目注册表 | 不允许任意 audience |
| 身份输出是否仍有效 | 会话及映射版本 | 不续签已撤销关联 |
不能仅提交 WAT 或“获取 WAT 成功”的布尔值来创建该会话，因为它们不是这个自建入口的验证契约。
9.5 凭证存储与故障恢复
入站凭证、WAT、资源 Token 分别使用独立变量和用途类型，避免通用 token 字段被错发。缓存至少按用户、工作负载、提供商和目标作用域隔离；不将用户 Token 放入持久任务描述或模型上下文。
用户完成 OAuth 后 Agent 重试获取凭证应复用原授权事务，避免重复发起多份关联。超时不能直接意味着绑定失败，先按供应商支持的状态契约核对，再决定重试。撤销之后缓存命中也必须受本系统会话状态约束。
9.6 运维排查表
| 现象 | 首查位置 | 禁止的临时修复 |
|---|---|---|
| Runtime 返回认证失败 | 入站模式及 JWT 配置 | 切换免认证入口 |
| 托管身份无法手工取 WAT | 是否误用自建身份路径 | 复制另一 Agent 的身份 |
| 用户拿到他人凭证 | userId 来源、会话回调和缓存键 | 共享一个“公共用户” |
| 三方 Token 失效 | 资源方撤销/到期与 provider 配置 | 借用管理员 Token |
| 项目拒绝 WAT | 是否用错目标凭证 | 只解码不验证 |
验收 A1—A6 应分别保留测试配置、去敏请求标识、预期与实际结果。AWS 请求 ID 与本系统 trace ID 一起保存，便于区分云端拒绝和项目拒绝。