摘要

  • draft-tulshi-oauth-transactional-access-tokens-00 为每个资源端生成不同的交易标识，并要求授权服务器对每次令牌请求重新执行策略。
  • 这种设计降低资源端直接关联，却不隐藏于授权服务器；五分钟令牌也不会缩短 refresh token、client credential、同意或客户端权力的寿命。

这份初稿发布于 2026 年 9 月 29 日，是目标为 Standards Track 的个人 Internet-Draft。它不是 OAuth 工作组文件，不代表 IETF 共识，也不是 RFC。现有来源没有证明实现、互操作或部署效果。值得报道的是它重新切开了几个经常被“已授权”三个字混在一起的状态。

Txn-AT 以 RFC 9068 的 JWT access token 为基础，却使用 txnat+jwt 类型。陌生消费者应拒绝它，而不是当作普通 at+jwt 后忽略交易语义。aud 必须只有一个资源服务器；txn 必须存在；tctx 与 rctx 只能承载授权服务器评估后愿意背书的交易与请求上下文。

一次请求的根仍然可能是 refresh token、client credential 或 token exchange 的来源令牌。授权服务器即使验证了这些凭证，也必须重新跑策略，并可拒绝本次交易。新交易还会得到一个至少含 128 位熵的 opaque handle；它绑定客户端、主体，并在适用时绑定 sender-constraining key。

同一 handle 可以为另一资源端请求新的 Txn-AT。于是必须保留六层证据：长期凭证说明谁能提问；策略回执说明为何此刻批准；handle 连接同一交易；每个 Txn-AT 只面向一个资源端；内部 Txn-Token 把经过选择的上下文带入该端的信任域；执行回执才说明资源实际做了什么。

短寿命没有切断第一层。草案明确说，同意与客户端权力可以长期存在，令牌才是逐交易的。用户可能只在 authorization code 流程中同意一次，之后 refresh token 不再要求用户交互。攻击者若偷到根凭证，未必自动通过策略，却获得不断请求的能力。

因此真正的控制不是 exp，而是每次评估是否新鲜、可解释、可拒绝。服务器不得未经判断就把客户端输入抄进 tctx 或 rctx。策略需要观察主体、认证强度、客户端登记、attestation、资源、授权细节与环境。签名只能证明服务器说过这些话，不能证明输入没有过期，规则没有错误。

每个 audience 的 txn 不同，确实阻止两个资源端仅凭这一字段做等值连接。服务器可以存映射表，也可用内部交易 ID 与 audience 做 HMAC 派生。但 client_id 仍相同，时间相近，主体未必 pairwise，上下文还可能包含金额、目的地或工作流指纹。授权服务器始终知道内部 ID。

这让 K_txn 同时成为隐私与审计资产。无状态派生减少数据库，却要求轮换、保留退役密钥或记录版本。密钥与内部状态一起泄露时，跨资源关联能力随之泄露。设计把横向可见性收窄，同时把纵向可见性集中。

重放也没有消失。Bearer Txn-AT 可在有效期内再次使用。草案推荐 DPoP 或 mutual TLS，并允许需要单次使用的资源端记录 jti，但没有强制。对支付、删除或基础设施变更而言，300 秒足以产生多次不可逆效果。

txn 也不是业务幂等键。它不能决定两次 HTTP 请求是否应合并成一次效果，更不能让多个资源端原子提交。RS1 已完成而 RS2 失败时，JWT 不会自动回滚。应用仍需请求 ID、重复效果规则、commit 回执与补偿流程。

正确实现必须从失败路径证明。Txn-AT-only 路由要拒绝普通 access token；内部 workload 要拒绝把外部 Txn-AT 当作 txntoken+jwt；多 audience、过期 handle、错误客户端、不同主体或错误 key 都要失败。登记 metadata 只能表达意图，不能证明每条生产路径都执行了规则。

这正是薄协调层的边界。公共格式可以携带精确类型、audience、来源与经过评估的上下文；授权服务器的策略不能因此变成普遍真理，令牌被接受也不能替现实宣布结果。证据可以移动，判断仍须可替换，执行仍须另行观察。

来源