SEP-2468：建议在 MCP 授权响应中使用签发者（iss）参数

社区译文；来源： MCP 29affa6b

摘要

本 SEP 提议建议在模型上下文协议（MCP）授权响应中包含显式的签发者（iss）参数，并要求对其进行验证，以缓解授权混淆攻击。通过将授权响应绑定到特定授权服务器身份，MCP 客户端可以可靠地检测并拒绝来自非预期签发者的响应，从而提高协议在多身份提供商（IdP）环境中的稳健性。本 SEP 遵循 RFC 9207 定义的规范。

动机

模型上下文协议越来越多地运行在多台授权服务器、多个身份提供商和中间组件共存的环境中。在这类环境中，OAuth 混淆攻击成为现实威胁。混淆攻击是指攻击者使客户端将授权响应关联到错误的授权服务器，从而可能导致 token 泄露或权限提升。

OAuth 规范描述了两种缓解混淆攻击的方法：要求使用签发者（iss）参数，或为客户端交互的每个签发者使用唯一的 redirect_uri。客户端 ID 元数据文档（推荐的注册方式）无法为每个签发者使用唯一的 redirect_uri；对于动态客户端注册，这种做法的运维成本也很高。因此，本提案建议 MCP 环境使用签发者缓解措施。

要求 MCP 授权响应包含显式 iss 参数，可以通过一种简单、可互操作且已得到充分理解的机制，将响应绑定到正确的授权服务器，并从设计上防止混淆攻击。不过，并非每台授权服务器都会发送签发者参数，因此本 SEP 对客户端提出如下要求：如果提供了该参数，客户端 MUST 验证签发者；对于支持 MCP 场景的授权服务器，则规定为 SHOULD。未来 SEP 和版本可能会将该 SHOULD 改为 MUST。

规范

签发者参数要求

MCP 授权服务器 SHOULD 按照 RFC 9207 的定义，在授权响应（包括错误响应）中包含签发者（iss）参数。采用此行为的授权服务器 MUST 在其授权服务器元数据中设置 authorization_response_iss_parameter_supported: true 以声明支持。

iss 参数 MUST：

• 与通过元数据发现所声明的签发者标识符完全一致
• 是使用 https scheme 且不包含 query 或 fragment component 的 URL（RFC 8414 第 2 节）

客户端验证要求

MCP 客户端 MUST 通过以下步骤验证授权响应中的 iss 参数：

• 确定该授权请求的预期签发者
• 将收到的 iss 值与预期签发者进行比较
• 如果两者不完全一致，则拒绝授权响应

如果签发者验证失败，客户端 MUST 将响应视为无效，并中止授权流程。

理由

iss 值已经用于 OpenID Connect 和基于 JWT 的 token 验证。将其用途扩展到 MCP 授权响应可以：

• 利用现有生态的知识和工具
• 避免引入 MCP 特有的安全机制
• 为部署提供清晰且可审计的安全保障

考虑过的替代方案

引入 MCP 特有的签发者绑定字段

• 已否决，选择复用既有 OAuth/OIDC 机制。

要求每个签发者使用唯一的 redirect_uri

• CIMD 元数据文档是静态的，无法枚举所有签发者；对于 DCR，这在技术上可行，但 DCR 在 MCP 部署中存在运维缺点，不适合作为一项安全属性的依赖。RFC 9207 可以统一适用于各种注册方式。

当服务器未声明支持时丢弃 iss（严格遵循 RFC 9207 §2.4 的 SHOULD）

• RFC 9207 §2.4 建议客户端 SHOULD 丢弃来自未设置 authorization_response_iss_parameter_supported 的服务器、且携带 iss 的响应，但同时明确将决定权留给本地策略（“具体指导不在本文范围内”）。本 SEP 改为规定执行比较。记录的签发者始终来自客户端已经按照 RFC 8414 §3.3 验证过的元数据文档，因此可以将收到的 iss 与一个可信基线比较；不匹配时仍无条件拒绝，唯一的行为差异只是接受 iss 与该基线匹配的响应，这并未放宽安全要求。实践中，授权服务器往往先开始发送 iss，随后才更新元数据；在此期间丢弃响应会拒绝合法流程，却没有安全收益。

向后兼容性

iss 参数是线上的加法扩展。客户端验证会给以下主机带来行为变化：其授权服务器声明了 authorization_response_iss_parameter_supported: true，但回调处理尚未将 iss 传递给 SDK；这些流程将被拒绝，直到主机像提取 code 一样从重定向 URI 中提取 iss。SDK 应以加法方式扩展回调签名（例如增加可选的 iss 参数），使现有调用点仍能通过编译。未声明支持的授权服务器不受影响。随附的 RFC 8414 第 3.3 节元数据验证要求，是对现有 RFC MUST 的重述；此前未执行该要求的客户端，升级时可能暴露潜在的签发者配置错误。

安全影响

本提案是对混淆攻击的一项缓解措施；该机制自身的安全注意事项记录在 RFC 9207 第 4 节。尤其需要注意，该缓解措施依赖客户端在重定向前确定预期签发者，并使用精确的简单字符串比较。另请参阅 MCP 安全最佳实践。

参考实现

• Go SDK：modelcontextprotocol/go-sdk#859
• TypeScript SDK：modelcontextprotocol/typescript-sdk#1957

两个实现都会在重定向前记录预期签发者，并比较收到的任何 iss；只有服务器声明支持时，缺少 iss 才会被拒绝。

致谢

感谢 Sam Morrow、Max Gerber、Aaron Parecki、Stephen Halter、Nate Barbettini、Karl McGuinness 和 Den Delimarsky 在 Auth Mix-Up Attack Prevention 工作组中所做的评审与讨论。