Amazon Bedrock AgentCore Identity 支持 Private Key JWT 认证：无需共享密钥，KMS 签名更安全
AWS Bedrock AgentCore Identity 新增 Private Key JWT 客户端认证，代理通过 KMS 签名 JWT 向身份提供商验证身份，无需共享 OAuth 客户端密钥。本文详解工作原理、三种授权流程（M2M/OBO/用户委托）及配置步骤，对国内使用 AWS 构建 AI 代理的开发者有直接参考价值。
一句话看懂
Amazon Bedrock AgentCore Identity 新增 Private Key JWT 认证，代理用 KMS 签名 JWT 替代共享密钥，安全调用下游 API。
详细发生了什么
Amazon Bedrock AgentCore Identity 现在支持 Private Key JWT 客户端认证。传统 OAuth 2.0 客户端认证依赖共享的 client secret，而 Private Key JWT 让代理使用一个签名的 JSON Web Token (JWT) 作为客户端断言，向身份提供商的 token 端点验证身份。
具体流程：代理调用 AgentCore Identity 的 GetResourceOauth2Token 请求 token → AgentCore 读取凭证提供者中的 client ID、KMS key ARN 和签名算法 → 构建短时效 JWT 断言 → 调用 kms:Sign 用 KMS 非对称签名密钥签名（私钥永不离开 KMS）→ 将签名后的断言发送给身份提供商 → 提供商用注册的公钥验证 → 返回 access token 给代理 → 代理用该 token 调用下游 API。
支持三种授权流程：
- 机器对机器 (M2M)：代理以自身身份访问资源，使用 client_credentials grant。
- On-behalf-of (OBO)：代理代表已登录用户，交换用户 token 获取下游 token。
- 用户委托访问：用户交互式授权后，代理获取代表用户的 token，使用 authorization code grant。
配置步骤包括：在 KMS 创建非对称签名密钥（支持 RS256/PS256/ES256）、导出公钥注册到身份提供商、在 Bedrock AgentCore 控制台创建 OAuth 客户端并选择 Private Key JWT 认证方式。
中文圈视角
对国内 AWS 用户来说，这项功能直接解决了 AI 代理调用内部 API 时的安全认证痛点。国内很多企业使用自建 OAuth 服务或第三方 IdP（如 Authing、飞书开放平台），传统 client secret 方式存在泄露风险，而 Private Key JWT 将私钥托管在 KMS，符合国内等保和密钥管理规范。
相比国内云厂商的类似服务（如阿里云百炼 Agent 的 API 密钥认证），AWS 的方案更细粒度：支持 OBO 和用户委托流程，适合需要用户身份透传的场景（如客服代理查询用户订单）。但需要注意，国内身份提供商（如企业微信、钉钉）是否支持 Private Key JWT 认证方式？目前多数国内 IdP 仍以 client secret 为主，但 Okta、Azure AD 等国际 IdP 已支持。如果使用自建 OAuth 服务，需确认支持 JWT bearer assertion。
另外，KMS 的密钥策略中 kms:ViaService 条件限制了只能通过 AgentCore Identity 调用，这符合最小权限原则，对安全审计友好。CloudTrail 会记录每次签名操作，便于合规审查。
几条值得记住的细节
- 签名算法支持 RS256、PS256、ES256，需与身份提供商和 KMS 密钥规格一致。
- 私钥永不离开 KMS，AgentCore 只调用 kms:Sign，不接触私钥材料。
- 支持三种授权流程：M2M、OBO、用户委托，覆盖常见代理场景。
- 配置时需在 KMS 密钥策略中添加 kms:ViaService 条件，限制仅 AgentCore Identity 可用。
- 公钥注册格式需按身份提供商要求转换（如 X.509 证书或 JWK）。
一句话总结
用 KMS 签名代替共享密钥，AWS 让 AI 代理调用内部 API 更安全，但国内 IdP 兼容性需提前确认。