OAuth 补救需要记录权限增量

摘要

draft-ietf-oauth-rar-metadata-remediation-00 允许资源服务器在令牌有效但授权详情不足时，通过 insufficient_authorization 返回可直接用于新授权流程的 RAR 对象。
资源服务器表达“什么对本次操作才算足够”，但并不授予权限；客户端决定是否继续，授权服务器执行校验与策略，资源所有者可以拒绝或缩小请求，资源服务器再判断新令牌能否使用。
Daniel Kade 提出一份权限增量记录，把失败操作、现有权限、补救提案、模式来源、同意结果、实际授予内容与最终资源效果连接起来。这是协议之外的治理建议。

当拒绝消息开始起草下一份授权请求

传统的 OAuth 错误处理有一个明显断层。资源服务器知道请求为什么不能执行，授权服务器知道怎样授予权限，客户端却未必知道应该向后者提交怎样的结构。于是，用户看到的是笼统报错，开发者依赖站外文档，不同机构之间则通过私有约定补齐细节。

OAuth 工作组的 RAR 元数据与错误补救草案试图填上这个断层。资源服务器收到有效令牌后，如果发现缺少的不是普通 scope，也不是更强的认证上下文，而是细粒度的 authorization_details，就可以返回 HTTP 401 和新的 insufficient_authorization 错误。authorization_remediation 参数携带经过 base64url 编码的 JSON，其中推荐放入根据失败请求构造的授权详情，还可以带一个不透明的 authorization_reference。

客户端先在同一用户会话、同一资源服务器来源下查找与该引用关联的令牌。如果没有合适的候选，便可以把资源服务器给出的详情直接放入新的 OAuth 授权请求。授权完成后，再用获得的令牌重试原操作。

这种机制有实际价值。RFC 9396 已经把细粒度授权从自由文本提升为结构化对象，却没有提供通用的类型发现与拒绝后补救路径。新草案增加授权详情类型元数据端点、JSON Schema 或模式 URI、错误信号与客户端处理规则，减少每个 API 单独发明恢复流程的需要。

同时，制度状态不能被便利性放大。版本 00 发布于 2026 年 8 月 23 日，Datatracker 将它列为 OAuth 工作组文档，并注明它替代此前的个人草案。IETF 126 会议纪要记录了对问题空间的支持、对方案的争论以及发起采纳的决定。这仍不是 RFC，也没有 IESG 电话会议日期；草案中的新 IANA 值只是申请，并非已经完成的分配。

提出充分条件，不等于授予权力

草案让资源服务器承担了一项以前常留在站外的工作：它要根据被拒绝的资源请求，构造能够补救问题的授权详情。文本还说，如果新的成功授权包含这些详情，就应当满足资源的要求。换言之，资源服务器写下了一份有后续效力的权限提案。

但权力并没有因此集中到资源服务器。客户端可以不处理挑战。授权服务器要验证详情类型、执行自己的政策并选择适用的授权流程。RFC 9396 要求授权服务器向用户呈现所请求的权限，资源所有者可以只批准其中一部分。令牌响应必须说明实际授予的授权详情。资源服务器在收到新令牌后仍要重新执法。

因此，“资源服务器给自己加权限”是不准确的；“客户端只是重试”同样不准确。准确的说法是：执法方提出了一组它愿意接受的条件，其他参与者随后决定是否把这些条件变成可用权力。

两次调用之间的差异可能很小，也可能决定实际后果。客户端原本只想读取一次账户信息，补救对象却可能描述持续访问；原操作是单笔支付，提案可能包含周期性授权；设备位置或风险状态变化，也可能让资源服务器要求另一组详情或更强流程。权限可能变窄、变宽、保持等价，也可能根本无法比较。

不能用 JSON 长短判断。RFC 9396 明确指出，由于各 API 自己定义字段语义，不存在比较任意两个授权详情对象的标准方法。少一个字段可能意味着启用更宽的默认值；数组可能代表多个能力的并集；换一个资源标识符可能把授权对象从一项资产移到另一项。结构有效，只证明它符合语法，不证明它最小、适当或符合用户目的。

不透明引用只负责找候选令牌

authorization_reference 的设计目标很克制：让客户端不必理解复杂 RAR 对象，也能从令牌包里找出可能合用的一个。资源服务器应当为相同或语义等价的详情生成稳定值；客户端只做字符串比较，并把关联限制在同一资源服务器来源与同一最终用户会话。

草案还要求它不得泄露敏感信息，客户端不得解析其含义，不得跨资源服务器使用；若令牌只允许单次使用，资源服务器不应返回该引用。这些规则阻止引用变成全局身份或隐藏的权限描述。

即便引用相同，也不保证令牌会被接受。用户可能已经撤回同意，地理位置或设备状态可能使风险政策改变，授权服务器也可能只签发了请求详情的子集。引用命中只说明找到了候选项，最终判断仍在资源服务器。

引用不同也不代表权限必然不同，更不表示谁大谁小。草案举例说，允许最高 100 的周期扣款令牌，可能覆盖金额 80 的请求，即使两次补救引用不同。是否包含，需要由具体授权类型的语义决定；不透明字符串本身没有偏序关系。

这对运维界面很重要。“引用命中”不能显示成“授权充分”，“引用变化”也不能自动解释成“继续申请即可”。前者把检索结果冒充执法结果，后者把未知的权限变化藏进恢复逻辑。

模式能验证形状，不能验证目的

草案提出的授权详情类型元数据，可以包含说明、文档、示例、信息性版本，以及内嵌 JSON Schema 或模式 URI。模式必须描述单个对象，并把 type 限定为相应标识符。这有利于客户端构造对象，也有利于授权服务器拒绝未知字段、错误类型与缺失的必填项。

然而，草案同时划清边界：说明文字不能用于授权或校验，示例不具规范性，版本字段也不代表自动的语义版本协商。一个付款对象可以完全符合模式，却仍然超出用户意图；一个医疗访问对象可以字段齐全，却没有合理的业务依据。

模式的来源仍应进入证据。若客户端在拒绝发生后读取了新模式，或者授权服务器使用的是另一个缓存版本，相同字段名可能被不同政策解释。至少应保留模式 URI、内嵌模式哈希、获取时间，以及执行语义判断的政策模块版本。

授权服务器的选择也不是透明细节。如果当前授权服务器不支持该详情类型，客户端可以依据受保护资源元数据发现替代服务器。换一个发行者意味着可能换了客户端注册、认证方法、同意界面、数据保留与组织责任。只要大家都讲 OAuth，并不代表制度边界没有变化。

权限增量记录

我建议在协议之外建立一份权限增量记录。它不进入令牌，不发明新的头字段，也不要求 IETF 修改草案。它只负责让一次顺滑的补救流程保留可审计的分界。

第一部分记录拒绝：最终用户会话、资源服务器来源、失败操作类别、请求的安全摘要，以及所提交令牌的有效 scope 或授权详情。账户号、病历、地址和精确交易条件不应复制进通用日志；可用短期不透明句柄、受保护引用或带盐承诺代替。

第二部分冻结提案：解码后 authorization_remediation 的哈希、对预期效果的最小可读说明、引用值、详情类型、模式 URI 或模式哈希、信息性版本与获取时间。具体类型的评估器把权限差异标为不变、收窄、扩大、不可比较或未知，并记录所用政策版本。

第三部分记录处置。客户端是放弃、复用令牌、发起新授权、要求用户确认，还是转交人工审批？选用了哪个授权服务器，是否从原发行者切换？用户看到的是哪个同意界面版本？资源所有者批准、缩小或拒绝了什么？令牌响应声称实际授予了哪些详情？

最后一部分跟随重试：在会话与来源边界内保存令牌—引用关联但不保存令牌本身；区分缓存令牌尝试与新授权尝试；记录资源服务器的最终决定，以及付款、读取或基础设施变更的实际结果和回滚引用。

这样，每个参与者只证明自己有权证明的事实。资源服务器证明它提出了什么；客户端证明如何处理；授权服务器证明展示与签发；资源所有者关联到实际选择；受保护系统证明最终效果。任何一方都不需要假装看见了全流程。

审计不能反过来制造敏感数据仓库

RAR 对象可能包含银行、医疗、位置与交易信息。补救草案建议资源服务器不要在可执行详情里放敏感值，也允许使用不透明句柄。对授权服务器，它建议在把详情放入 JWT 之前评估体积与隐私，必要时通过经过认证的令牌自省把数据交给资源服务器。

权限增量记录也应遵守最小化原则。对可枚举金额做无盐哈希并不匿名；把完整账户号写入“审计日志”，也不会因为日志受控就自动合理。可读说明应描述操作效果，而不是复制业务数据。详细比对材料应留在受保护域内，并有明确保留期限。

还要保存信息来源。资源服务器给出的句柄不是用户声明；模式说明不是同意证据；令牌中出现授权详情，也不能证明用户真正理解了界面。来源标签让审计稍显繁琐，却能避免把技术对象洗成过强结论。

限制重试次数之外，还要限制权限变化

草案已经防范最明显的循环：最多用缓存令牌重试一次，再做一次新授权；如果新令牌立即得到同一引用，就应停止并报错。引用不同可以再次补救，但实现必须设置上限。令牌存储还必须按最终用户会话隔离。

这些规则约束机械重复，却不判断连续几份提案是否逐级扩大权限。变化的引用可能来自合法上下文，也可能来自不稳定政策，或形成一条“再多给一点”的台阶。除了次数预算，还需要权限预算：新发行者、新资源类别、高影响动作、更长周期、持续权限、模式变更，以及无法比较的对象，都应触发显式解释或问责审核。

建设性的结果不是阻断补救，而是正确命名补救。使用已有权限再次发送，才是普通重试；把资源服务器的详情带去申请新权限，是一次新的授权决定。协议负责把提案可靠地送达，治理记录负责防止差异在成功页面出现之前消失。

OAuth 补救挑战提出的是新权限，不只是重试提示

为何重要

摘要

当拒绝消息开始起草下一份授权请求

提出充分条件，不等于授予权力

不透明引用只负责找候选令牌

模式能验证形状，不能验证目的

权限增量记录

审计不能反过来制造敏感数据仓库

限制重试次数之外，还要限制权限变化

来源

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报