摘要

  • Justin Richer 于 9 月 28 日提交个人 Internet-Draft，提出让浏览器辅助页显示一个可复制的值，供远程 OAuth 客户端粘贴并取回授权码。
  • 这解决的是交接步骤，不是新增安全保证：辅助页仍收到 code 和 state，客户端仍要认清待完成的请求及预期授权服务器。

用户在笔记本浏览器里批准访问，真正运行客户端的却是一台远程机器。后者没有浏览器能够访问的回调地址，授权码于是不能像常见的本地应用那样直接返回。draft-richer-oauth-oob-authcode-00 把已注册的辅助网页放在回调位置，再让用户把网页上的一个值粘贴回等待中的终端。这是 2026 年 9 月 28 日提交、拟作为信息性文档的个人草案。Datatracker 状态为 I-D Exists；不能称它已获工作组采纳、IETF 批准或成为 RFC。

草案并没有发明新的授权类型。授权服务器仍按授权码流程把响应送往登记过的重定向 URI。辅助页读取 code 与 state，借助从 state 派生的 HKDF 材料、XOR 和校验值生成一段可复制文本。远程客户端早已保存原始 state，收到粘贴值后可还原授权码，再到原定的令牌端点完成交换。服务器方面需要的是接受该辅助页为登记的回调地址，而不是另开一套协议。

容易误读的是“组合”二字。草案明确说，这些运算并不比基本授权码流程多带来一层安全性；它们也没有让浏览器收到的授权码变成端到端保密信息。辅助网页可以是无需服务器会话状态的静态页面，但托管者、CDN、镜像或缓存仍可能从 GET 请求的 URL 看到 code 和 state。如果访问日志保存了该 URL，页面是否静态并不能抹去这条接收链。

组合值也不是授权服务器的证明书。任何人都可以用任意输入运行同一算法。客户端必须用自己手中的待处理请求、保存的 state、预期服务器与令牌端点，判断这个值是否属于当前交易。无法保留 state 的无状态客户端不能采用这条组合路径。草案还提到 JavaScript 失效时可让用户复制完整 URL；那是直接搬运原始参数的退路，不能当成与组合值相同的保护方式。

另一个需要单独盘点的字段是 iss。草案的常规组合值只带 code 和 state，并不独立传回其他响应参数；第 3.4 节提出，若客户端知道服务器会发送 iss，将来或可把它用于 HKDF 的 INFO。RFC 9207 已把签发方标识用于多授权服务器场景的混淆防范。不能据此断言每个采用新草案的客户端都会遇到攻击，也不能说 RFC 9207 被废止；准确的问题是，多服务器客户端如何继续保存原有的签发方绑定。

RFC 8628 的设备授权流程仍是另一种选择，需要服务器参与并进行轮询。新提案只是给不能直接接收浏览器回调的客户端提供另一条工程路线，并未要求弃用设备流程。少改服务器的吸引力很实际，代价却是在运维图上增加辅助页的来源、日志和人工复制环节。

资料