摘要

  • draft-ietf-oauth-deferred-token-response-00 用受发送者约束的 deferral_code 表示一项尚未完成的令牌请求；它不是访问令牌，也不给资源访问权。
  • 取消沿用 RFC 7009 撤销接口：真正取消与完全不改状态都可返回 HTTP 200。因此，支持能力发现和随后返回 access_denied 的轮询是两份不同证据。
  • 若访问令牌已经交付，它就是一项寿命独立的凭据。撤销延迟码不会顺带撤销令牌，更不能证明资源操作已经停止。

一个为了保密而保持沉默的成功码

OAuth 撤销接口故意不告诉调用方，提交的值是不是有效令牌。这样做可以减少枚举和探测。代价是：200 OK 只能证明接口接受并处理了请求，不能说明处理过程中是否存在可改变的对象。

Deferred Token Response 第 00 版 把这条边界带到异步发令牌场景。人工审核、反欺诈或外部验证可能无法在一次 HTTP 请求内完成。客户端声明可接受 deferred 模式，授权服务器也选择延迟时，令牌接口返回 HTTP 400、authorization_pending、一个不透明延迟码、有效期和轮询间隔。

这不是换了名字的令牌。它只代表同一授权服务器上的一项挂起请求，不允许访问受保护资源。若原请求使用 DPoP 密钥或双向 TLS 证书，延迟码还绑定同一密钥或证书。拿到字符串但没有原发送者约束，并不等于持有同一凭据。

该文档目前只是 OAuth 工作组的活跃 Internet-Draft，不是 RFC，也不是部署普查。本文分析的是它写出的状态边界，而不是宣称生产系统已经采用。

两个同名计时器，管理两种对象

初次延迟响应里的 expires_in 是延迟码寿命。超时后再轮询会得到 expired_token。如果请求后来成功，最终响应也可能有 expires_in，但这一次它属于访问令牌。

字段同名不代表权限或计时可以继承。用第一个时间安排第二个凭据的刷新，会把挂起态和访问态压成一个错误生命周期。

interval 也必须由客户端保存。它只在初次响应出现；后续 authorization_pending 不再重复。收到 slow_down 后，间隔至少增加五秒。只保留“最新响应”的日志，无法判断客户端是否遵守节奏，也无法解释它是否自己制造了负载。

因此，证据必须同时标明对象、时间和观察者：延迟码何时过期，访问令牌何时过期，轮询规则何时改变，以及哪个执行实例持有正确的发送者绑定。

回调只负责唤醒，不负责宣判

客户端可以登记 HTTPS 回调。请求以成功、错误或取消任一方式结束时，服务器都会发送通知。通知携带延迟码，却不携带令牌和最终结果。它只说明：现在轮询，会得到终态。

每次请求专用的通知令牌可以认证回调来源。没有该令牌时，客户端要用其他方式保护端点，并把通知当作提示，直到轮询确认。即使完成认证，通知也只证明“谁发的”，不证明“最终是哪一支”。

草案建议配置回调后仍按 interval 轮询。回调降低等待；轮询抵抗通知丢失、延迟或被压制。两条路径只有在不相互冒充时，才真正形成冗余。

同一个 200 后面藏着互斥状态

取消时，客户端把原样延迟码交给 RFC 7009 撤销接口，并建议带上 deferral-code 类型提示。若服务器识别该码，且它属于已认证客户端，就必须原子地把挂起请求改成取消，阻止尚未开始投递的回调，并让后续轮询返回 access_denied。

但未知延迟码、其他客户端的码、已经兑换、已经取消或已经过期的码，也都返回 HTTP 200，并且不改任何状态。这是 RFC 7009 有意设计的不可区分性。

第 00 版为此定义 revocation_endpoint_token_type_values_supported 元数据。支持延迟码撤销的服务器必须列出对应类型。未声明支持的服务器仍会按 RFC 7009 对任何撤销请求返回 200。草案直接警告：若跳过能力检查，客户端可能无声地取消失败。

正确凭证链有顺序：先保存服务器当时的支持元数据，再记录取消请求和传输结果，最后轮询并观察 access_denied。200 不是无用；它只是位于链条中间，而非结尾。

令牌交付把竞态切成三段

第一段是仍在等待。取消赢得竞态后，状态进入 cancelled。

第二段是审核已成功提交，但令牌还没有交付。此时取消会形成“已兑换、随后取消”的状态；之后不得发令牌，轮询返回 access_denied。

第三段是令牌已经交付。撤销延迟码不得顺带撤销访问令牌，因为两者是寿命独立的凭据。若目标是切断访问，客户端必须单独撤销访问令牌，并视风险验证资源服务器是否还接受它。

回调也可能在取消前已经出发。草案只要求压制尚未开始投递的回调。一个晚到通知可以与有效取消同时为真；消费者不能据此重开流程，更不能把它解释成成功。

所以“已取消”必须附带交付边界：尚挂起、已解析未交付、或令牌已交付。没有这项信息，工单无法决定下一步动作。

同意可能比延迟码更早失效

延迟码可能有效数小时甚至数天。在此期间，资源所有者可以撤回同意，客户端可能被禁用，会话也可能结束。服务器在真正发令牌前必须重新检查这些条件；外部审核通过不能覆盖已经失效的授权基础。

之后，资源服务器还要依据 scope 和本地策略决定是否接纳。有效令牌不证明某项操作获准；获准也不证明业务动作完成。每一层都有自己的权力和观察者。

最小凭证要保存分歧，而不是保存秘密

一份本地取消凭证应保存授权服务器标识及支持元数据摘要、客户端身份及绑定密钥引用、延迟码的单向关联值、初次响应时间、有效期和轮询间隔、取消请求及重试谱系、确认轮询、回调状态，以及令牌响应是否越过交付边界。

它不应把真实延迟码写进通用日志。草案要求像刷新令牌一样保护和脱敏这项秘密。若令牌已经交付，再附上独立撤销凭证；若风险指向真实操作，再附上资源接纳和受控事务结果。

这是一种最小初始证据格式，不是全球取消登记处。不同产品可以保留自己的存储、权限和修复策略，只需让最关键的状态可比较。

Lu Heng 的“现实层”框架解释了为什么不能越级。HTTP 200 是符号回应；取消是服务器内的状态迁移；access_denied 是协议可见观察；令牌撤销是另一项凭据事件；资源操作才是可执行结果。证据向运行代码下沉时变强，重复第一条消息只会制造表面共识。

来源

  1. Deferred Token Response rev00
  2. DTR 修订历史
  3. DTR rev00 HTML
  4. DTR rev00 文本
  5. RFC 6749 — OAuth 2.0
  6. RFC 7009 — OAuth 撤销
  7. RFC 8628 — 设备授权许可
  8. RFC 8693 — 令牌交换
  9. RFC 8705 — OAuth mTLS
  10. RFC 9449 — OAuth DPoP
  11. RFC 9700 — OAuth 安全最佳实践
  12. IANA OAuth 参数
  13. Lu Heng — Minimum Initial Specification
  14. Lu Heng — On Reality Layers
  15. Lu Heng — Running Code Primary