摘要

  • RFC 9207 给 OAuth 客户端提供的是一张边界清晰的回执：授权响应里的签发者必须与本次请求预先记录的签发者完全一致；不一致就必须停止，不能把授权码送去下一站。
  • iss 标识的是授权服务器语境。它不认证用户，不验证授权码，不证明令牌已经签发，也不说明令牌的受众、权限或资源服务器最终决定。
  • 可审计的实现必须分别保存请求状态、预期签发者、元数据、响应签发者、比较结果、授权码兑换、令牌验证、资源决定和恢复动作，不能用其中一项替代全部流程。

最危险的回调看上去完全正常。

浏览器回到了登记过的重定向 URI。state 与客户端先前生成的值相同。响应中还有一枚诚实授权服务器签发的授权码。密码没有被钓走，授权码也没有被伪造。然而，如果同一个客户端能够接入多个授权服务器，它仍可能犯下决定性的路由错误：把这枚真实授权码发送给攻击者控制的 token endpoint。

问题不在某一条记录明显为假，而在两条各自可信的记录被错误拼接。第一条记录说明客户端开始流程时以为自己选择了哪一个授权服务器；第二条记录是经由用户浏览器返回的授权响应。OAuth 2.0 最初定义的响应并没有明确写出是谁生成了它。如果客户端让通用回调、浏览器跳转或恶意元数据抹去这条边界，真实凭证就可能跨进错误运营者的控制面。

RFC 9207 用一个刻意保持最小的字段修补这处缝隙。2022 年 3 月发布的 OAuth 2.0 Authorization Server Issuer Identification 是 IETF 标准轨道文件，由 Karsten Meyer zu Selhausen 与 Daniel Fett 共同撰写。支持该规范的授权服务器在成功响应和错误响应中都加入 iss，声明自己的签发者标识。客户端再把它与发出本次请求时记录的签发者比较。

如果两个字符串不相等，客户端必须拒绝响应，也不得继续授权流程。

这就是该字段的全部权限。它的价值也正来自这种克制。

原来的回调没有写明发送者

OAuth 有意拆分角色。资源所有者使用用户代理，客户端向授权服务器请求授权，随后把授权码提交到 token endpoint，最后持访问令牌访问资源服务器。角色分离让不同机构可以组合服务，也让“下一步该去哪里”成为不能由浏览器到达事实自动回答的问题。

RFC 6749 的授权响应包含授权码；如果请求带有 state，响应还要原样带回。state 非常重要，它把响应绑定到用户代理的已认证状态，并用于抵御跨站请求伪造。但它回答的是“这是否对应我先前建立的浏览器状态”，不是“这是谁发来的授权响应”。

当客户端只支持一个授权服务器时，差异可能长期隐藏，因为系统里没有第二套 endpoint 组合。第二个签发者加入后，客户端就不能只记住“这里有一个待完成的 OAuth 流程”，而必须记住这次流程属于谁。当前 OAuth 安全最佳实践 RFC 9700 明确要求：与两个或更多授权服务器交互的客户端必须防止 mix-up，并把预期签发者与每一项授权请求绑定。

Daniel Fett 的公开经历为这个问题提供了人物线索，却不应被写成个人发明神话。他的个人网站把他描述为专注身份和 Web 协议安全、参与 OAuth 与 OpenID Connect 工作的安全顾问。2026 年 9 月核查时，IETF Datatracker 在其名下列出四份 RFC，其中包括 RFC 9207。这些事实说明研究问题的延续性，却不意味着他独自拥有该规范，更不意味着他控制任何现实部署。

一个签发者对应一组端点

签发者标识不是展示给用户看的品牌名。RFC 8414 将它定义为不含查询部分与片段的 HTTPS URL。它锚定一份授权服务器元数据，元数据可以列出 authorization endpoint、token endpoint、公钥位置以及其他能力。同一主机甚至可以通过不同路径承载多个签发者。

真正需要保护的是整组 endpoint 的组合关系。用户可能看到了诚实服务器的授权页面，客户端却从恶意配置中拿到了攻击者控制的 token endpoint。RFC 9700 特别提醒，仅保存 authorization endpoint 的 URL 不足以抵御 mix-up：恶意方可以声称使用某个诚实授权地址，同时把兑换授权码的地址指向自己。签发者因此不是一张名片，而是预期端点组合的稳定索引。

RFC 9207 把经浏览器返回的响应重新连接到这组元数据。使用 RFC 8414 时，响应中的 iss 必须与元数据中的 issuer 完全相同，服务器还可以用 authorization_response_iss_parameter_supported: true 声明支持。客户端提取并按表单编码规则解码 iss，再以简单字符串比较核对本次请求的预期值。

这里没有“意思差不多”。路径不同、多出一条斜线，或者同一主机上的另一个签发者，都不能凭肉眼相似被接纳。它不是语言判断，而是确定性的路由决策。

决策权仍在本地。授权服务器声明自己，元数据描述端点组合，客户端选择签发者、保存支持状态、执行比较并决定中止。没有一个全球机构代替客户端完成这一步。共同字段只提供最小接口，不接管运营者的未来选择。

相等只允许继续，不代表完成

最常见的误读，是给 iss 赋予超出规范的证明力。

签发者相等不等于资源所有者已经通过认证。授权服务器仍可能要求登录或返回错误。它也不证明用户理解并同意了请求的权限范围，那属于授权交互和产品策略。

相等也不验证授权码。客户端选择正确 token endpoint 后，该端点仍要检查授权码、必要时认证客户端，并核对重定向 URI 等条件。授权码可能过期、被重放、属于另一个客户端或因其他原因无效。

iss 更不证明令牌已经签发。它没有说明令牌类型、受众、scope、寿命、发送者约束或撤销状态。资源服务器在令牌真正到达时仍要独立判断。即使令牌有效且权限正确，也不能由此推断应用操作成功，更不能推断用户已经看到预期结果。

完整证据应当依次回答：客户端何时创建请求并把预期签发者与浏览器状态绑定；何时收到响应；响应写了什么 iss；比较是接纳还是中止；端点来自哪一版已验证元数据；授权码是否被正确端点接受；令牌如何被资源服务器验证和执行；最终业务结果与恢复记录是什么。

RFC 9207 负责的是比较这一环。把它称为“OAuth 成功”，等于删除后面所有决策者。

这个字段不是数字签名

普通授权响应中的 iss 没有密码学完整性保护。RFC 9207 对此写得很清楚。只有把它误当成通用身份证书时，这一点才显得矛盾。

该规范处理的威胁更窄。在 mix-up 场景中，客户端收到的是未被攻陷的授权服务器生成的响应，只是误判了应当接收授权码的 endpoint 组合。如果攻击者已经能够在响应到达客户端前篡改它，那么攻击者也已经能直接读取授权码，不必再走 mix-up 这条路。因此 iss 在指定模型里消除路由混淆，却没有宣称抵御一切响应篡改。

需要完整性保护的系统可以采用更强封装。JARM 把响应参数放进签名 JWT；某些从 authorization endpoint 返回 ID Token 的 OpenID Connect 流程也可以携带签发者，只要客户端按规则验证。若一份响应出现多个彼此不一致的签发者标识，客户端必须拒绝。

这与“最小初始规范”相符：先加入足以显露歧义的最小共同信号，再让不同系统根据风险选择更强封装、兼容策略和迁移速度。RFC 9700 也允许按签发者使用不同的重定向 URI，前提是客户端真正执行核对。

兼容例外必须有到期日

现实世界不会让所有授权服务器同时升级。RFC 9207 因此要求客户端保存每个服务器的支持状态，而不是假定全球已经采用。

如果客户端知道某服务器支持 iss，那么来自该服务器却缺少 iss 的响应必须被拒绝。对于明确不支持的服务器，客户端可以按本地策略接纳无 iss 响应，也可以拒绝继续合作。服务器未声明支持却突然发送 iss，同样需要显式政策处理，因为它可能反映配置漂移。

灵活性不是免责条款，而是责任落点。多签发者客户端应有一份清单：每个签发者、元数据与 endpoint 组合、支持标记、信息来源与核查日期、遗留例外、例外负责人和退出日期。如果最后两项不存在，“兼容”就会变成永久绕过防线的通道。

第二个供应商的上线也必须被视为安全状态变化。单签发者时期无需 mix-up 防御，不代表旧客户端在扩展后仍安全。商业接入之前，请求级签发者状态就应进入运行代码。

运行系统真正可以证明什么

读过一次元数据不能证明部署合规。有效测试要从请求创建开始。

记录请求标识、用户代理绑定、所选签发者、元数据版本、authorization endpoint、token endpoint、支持标记和重定向 URI。响应返回时，记录是否出现 iss、解码后的值、预期值、比较结果，以及不匹配后是否真的阻止了授权码兑换。测试必须覆盖成功、授权错误、缺失、重复、未知签发者，以及同一主机不同路径的两个签发者。

最关键的是负向证明：发生不匹配后，任何包含授权码、客户端凭证或令牌的请求都不应到达意外 endpoint。客户端日志和受控测试端点的接收记录必须互相印证。只在界面上显示错误、网络请求却照样发出，并不构成防御回执。

事故分析也应保持层次。签发者不匹配证明比较失败，不自动证明某服务器遭到入侵。token endpoint 拒绝授权码，只证明这一端点拒绝了本次兑换。资源服务器拒绝令牌，更不能反向证明此前的签发者绑定正确。

iss 的成功标准很朴素：在秘密移动之前，让一个原本隐形的歧义变成必须回答的问题。它为服务器署名，却不替令牌、资源或业务结果作证。

来源