Keycloak 26.8 Token Exchange 委托机制解读：Agent 的身份 ID 是怎么进入令牌的 - 张善友
内容提要
Keycloak 26.8 将 Token Exchange 委托功能升级为预览，并新增面向 AI Agent 的客户端委托：用户同意后令牌携带 may_act 声明，Agent 通过双令牌交换获得委托令牌，其中 sub 为用户、act 为 Agent，实现身份与调用方分离。文章还梳理了 RFC 8693、ID-JAG、WIMSE 等标准进展及微软、Okta 等厂商方案，并指出撤销缺口与 CVE-2026-97846 等风险。
延伸解读
委托机制的核心：身份与调用方分离
Keycloak 26.8 的客户端委托让下游 API 在令牌中同时看到两个身份：sub 表示数据属主（用户），act 表示实际调用方（Agent）。这解决了以往 Agent 要么冒用用户令牌、要么使用高权限服务账号的归因难题。用户同意后令牌携带 may_act 声明，Agent 通过双令牌交换获得委托令牌，且委托令牌无刷新令牌、受众和范围收窄，降低了凭据泄露风险。
预览状态与升级风险
委托功能在 26.7 为实验状态，26.8 升为预览，但预览在 Keycloak 中默认禁用、不建议生产使用，且后续可能变更或移除。26.7 到 26.8 已发生破坏性改动：scope 从 delegation 改为 delegation:user 和 delegation:client，授权从 impersonation 角色迁移到 FGAP V2。此外，26.8 是需停机的次版本升级，跨版本升级需停掉所有旧节点迁移 schema，进行中的登录流程会丢失。
撤销缺口与 CVE-2026-97846 风险
委托令牌被设计为短寿命且无刷新令牌，但撤销原始令牌不会撤销已交换出的令牌，Keycloak 仅在交换产出刷新令牌时维护撤销链，因此短寿命访问令牌是主要缓解手段。另一个风险是 CVE-2026-97846：标准 Token Exchange V2 不执行 mTLS 持有者密钥绑定，配置了证书绑定令牌的客户端仍可能通过交换获得普通 Bearer 令牌。临时缓解包括改用 X509 证书认证、资源服务器强制校验 cnf 声明、轮换密钥并监控 TOKEN_EXCHANGE 事件。
选型参考：委托、冒充与跨域断言
委托适用于 Agent 和 API 都在同一信任域、且希望用户逐会话批准的场景；冒充是管理员进入用户会话，令牌带 act 且不可关闭；跨信任域场景（如企业 IdP 替 Agent 向第三方 SaaS 背书）则适合 ID-JAG 等跨域断言。Keycloak 26.8 的委托覆盖了厂商 Agent SSO 的令牌层，但不提供清单和发现层。选型时需根据信任边界和授权模型决定。
Q&A
Keycloak 26.8 的 Token Exchange 委托机制是什么？它如何让 AI Agent 的身份进入令牌？
Keycloak 26.8 将 Token Exchange 委托功能升级为预览，并新增面向 AI Agent 的客户端委托。用户登录时，客户端在 scope 中带上 delegation:client:actor-app，Keycloak 校验 actor-app 客户端存在、有服务账号且持有 FGAP V2 的 delegate 权限，用户同意后签发的令牌包含 may_act 声明（含 Agent 的服务账号用户 ID 和 client_id）。之后 Agent 用用户令牌和自身 client_credentials 令牌做双令牌交换，获得委托令牌：sub 为用户，act 指向 Agent，无刷新令牌，受众和范围取自 actor-app 配置。
在 Keycloak 26.8 之前，让 AI Agent 接入系统有哪些不体面的方式？
主要有两种：一是把用户的访问令牌直接塞给 Agent，问题包括令牌无受众控制、无范围收敛、无审计轨迹、用户未同意；二是给 Agent 配服务账号，甚至挂 Admin REST API 角色，凭据泄露后攻击面等同于管理员账号。2025 年 Salesloft-Drift 事件中，攻击者仅靠偷取的 OAuth 令牌就波及 700 多家组织的 Salesforce。
Keycloak 26.8 的委托机制与冒充（Impersonation）有什么区别？
冒充是管理员走进用户的会话，而委托是用户对一个指名的 Actor 预先授权，授权边界是 Actor 客户端自己的配置。在 26.8 中，冒充会话签发的令牌在访问令牌和 ID 令牌里都带 act 且关不掉，生命周期事件会带 impersonator 和 impersonator_id，自省端点返回的 act.sub 从用户名改为用户 ID。委托令牌则 sub 永远是用户，act 永远是 Agent，且不授予 Admin API 访问。
Keycloak 26.8 的委托机制有哪些安全边界和已知风险？
边界包括：may_act 可能被 Hardcoded claim 映射器旁路，26.8 新增 may-act 客户端策略执行器重新校验；撤销有缺口，撤销原始令牌不会撤销已交换出的令牌，只能靠短寿命访问令牌；CVE-2026-97846 漏洞：标准 Token Exchange V2 不执行 mTLS 持有者密钥绑定，配了证书绑定令牌的客户端仍能通过交换获得普通 Bearer 令牌，Red Hat 评 Moderate（CVSS 6.8），暂无修复版本。
如何为 AI Agent 客户端配置 Keycloak 26.8 的委托？关键步骤和常见坑是什么？
步骤：启用特性 token-exchange-delegation 和 parameterized-scopes；创建 FGAP V2 的 delegate 权限；登录客户端带 scope=openid delegation:client:actor-app 且开启 Consent required；用户同意后令牌带 may_act；Agent 用 client_credentials 拿自身令牌，再以用户令牌为 subject_token、自身令牌为 actor_token 做交换。常见坑：没有匹配的 FGAP V2 delegate 权限时，委托 scope 会被静默丢弃，登录成功但令牌无 may_act，Keycloak 以 WARN 记录。
Keycloak 26.8 的委托机制与 ID-JAG、WIMSE 等标准是什么关系？
Keycloak 的委托是 RFC 8693 委托语义的实现，使用参数化 scope、同意和 FGAP 策略，没有新协议。ID-JAG 用于跨信任域场景，由企业 IdP 签发身份断言 JWT 授权许可，Okta 的 Cross-App Access 是其产品化实现，MCP 规范已将其收为官方扩展。WIMSE 工作组正在制定 AIMS 草案，主张 Agent 不需要新协议，组合 WIMSE 和 OAuth 2.0 家族即可。Keycloak 在 ID-JAG 上支持消费侧（RFC 7523），发行侧还在提案阶段。
Agent 身份标识可以分为哪三个正交层？Keycloak 26.8 如何体现这些层？
三层：稳定身份（这个 Agent 是谁），Keycloak 用机密客户端的 client_id 加服务账号用户 UUID；实例身份（哪个运行实例在干活），OAuth 目前表达不了，有草案主张在 act 中带经 attest 的实例身份；委托上下文（代表谁、被谁授权、为哪个任务），RFC 8693 的 act 嵌套链、Keycloak 的 may_act、ID-JAG 的 sub+client_id+scope 组合。Keycloak 26.8 的委托中 sub 永远是用户，act 永远是 Agent，委托令牌是短寿命、窄受众的任务上下文。
Keycloak 26.8 的委托机制目前有哪些局限性？
主要局限：预览状态，默认禁用，不建议上生产，后续版本可能变更或删除；撤销缺口，撤销原始令牌不会撤销已交换出的令牌；多跳委托链的可验证性不足，RFC 8693 的嵌套 act 是声明不是密码学证明，跨组织三跳以上无完整可见性；同意疲劳，每会话重新批准对后台任务不友好；注册表层碎片化，Keycloak 刻意不做 Agent 注册表。
