Documentation Index
Fetch the complete documentation index at: https://mcp.zhcndoc.com/llms.txt
Use this file to discover all available pages before exploring further.
审核中标准跟踪
| 字段 | 值 |
|---|---|
| SEP | 2468 |
| 标题 | 建议在 MCP Auth 响应中使用 Issuer（iss）参数 |
| 状态 | 审核中 |
| 类型 | 标准跟踪 |
| 创建时间 | 2026-03-25 |
| 作者 | Emily Lauber (@EmLauber) |
| 赞助人 | @pcarleton |
| PR | #2468 |
摘要
本 SEP 建议在 Model Context Protocol（MCP）授权响应中包含并要求验证显式的 issuer（iss）参数，以缓解授权混淆攻击。通过将授权响应绑定到特定的授权服务器身份，MCP 客户端可以可靠地检测并拒绝来自意外 issuer 的响应，从而在多身份提供方（IdP）环境中提升协议的健壮性。本 SEP 遵循 RFC9207 中定义的规范。动机
Model Context Protocol 越来越多地运行在多个授权服务器、身份提供方和中介共存的环境中。在这种环境下，OAuth 混淆攻击成为一种现实威胁。混淆攻击是指攻击者使客户端将授权响应与错误的授权服务器关联，从而可能导致令牌泄露或权限提升。 OAuth 规范描述了两种缓解混淆攻击的方法：要求使用 issuer（iss）参数，或为客户端交互的每个 issuer 使用唯一的 redirect_uri。对于 Client ID Metadata Documents（推荐的注册方式），每个 issuer 使用唯一的 redirect_uri 并不可行；而对于动态客户端注册（Dynamic Client Registration），这样做在运维上成本较高。因此，建议 MCP 环境采用 issuer 缓解方案。 在 MCP 授权响应中要求显式的 iss 参数，提供了一种简单、可互操作且被广泛理解的机制，可将响应绑定到正确的授权服务器，并从设计上防止混淆攻击。不过，由于并非每个授权服务器都会发送 issuer 参数，本 SEP 建议客户端在提供该参数时必须验证 issuer，并建议支持 MCP 场景的授权服务器应当提供该参数。未来的 SEP 和版本可能会将 SHOULD 改为 MUST。规范
Issuer 参数要求
MCP 授权服务器 SHOULD 在授权响应中包含 issuer（iss）参数，包括错误响应，如 RFC9207 所定义。这样做的授权服务器 MUST 通过在其授权服务器元数据中设置authorization_response_iss_parameter_supported: true 来进行声明。
iss 参数 MUST：
- 与通过元数据发现所声明的 issuer 标识符完全匹配
- 是一个使用
https方案、且不包含查询或片段组件的 URL（RFC 8414 第 2 节）
客户端验证要求
MCP 客户端 MUST 通过以下方式验证授权响应中的 iss 参数：- 确定该授权请求所预期的 issuer
- 将收到的 iss 值与预期 issuer 进行比较
- 如果两者不完全匹配，则拒绝该授权响应
原因说明
iss 值已经在 OpenID Connect 和基于 JWT 的令牌验证中使用。将其扩展到 MCP 授权响应中：- 可利用现有生态系统中的知识和工具
- 避免引入 MCP 特有的安全机制
- 为部署提供清晰且可审计的安全保障
已考虑的替代方案
引入 MCP 特有的 issuer 绑定字段- 因为复用已有的 OAuth/OIDC 机制更合适，所以被否决。
- CIMD 元数据文档是静态的，无法枚举每个 issuer；使用 DCR 在技术上可行，但在 MCP 部署中，DCR 有运维上的缺点，因此不适合依赖它来实现安全属性。RFC 9207 可统一适用于各种注册方式。
iss（严格遵循 RFC 9207 §2.4 的 SHOULD）
- RFC 9207 §2.4 建议，当客户端收到来自未设置
authorization_response_iss_parameter_supported的服务器的iss响应时，应丢弃该响应，但明确将该决定留给本地策略（“具体指导超出范围”）。本 SEP 选择进行比较。记录的 issuer 总是来自客户端已经按照 RFC 8414 §3.3 验证过的元数据文档，因此，只要iss存在，就可以将其与可信基线进行检查；不匹配时仍然必须无条件拒绝，所以唯一的行为差异就是接受一个其iss与该基线匹配的响应——这并不是放宽要求。实际上，授权服务器常常会在其元数据更新之前就开始发出iss，而在这段窗口期内直接丢弃会在没有安全收益的情况下拒绝合法流程。
向后兼容性
iss 参数在协议线上是增量式添加的。对于那些授权服务器已声明 authorization_response_iss_parameter_supported: true，但回调处理尚未将 iss 传递给 SDK 的主机而言，客户端验证会引入行为变化；在主机从重定向 URI 中连同 code 一起提取 iss 之前，这些流程都将被拒绝。预计 SDK 会以增量方式扩展回调签名（例如增加一个可选的 iss 参数），以便现有调用点仍可继续编译。未声明支持的授权服务器不受影响。随附的 RFC 8414 第 3.3 节元数据验证要求重申了一个现有的 RFC MUST；那些此前并未强制执行该要求的客户端，在升级后可能会暴露潜在的 issuer 配置错误。
安全影响
本提案是对混淆攻击的一种缓解措施；该机制本身的安全考量已在 RFC9207 第 4 节 中说明。特别是，该缓解依赖于客户端在重定向之前建立预期 issuer，并且依赖于精确的简单字符串比较。另请参阅 MCP 的 安全最佳实践。参考实现
- Go SDK: modelcontextprotocol/go-sdk#859
- TypeScript SDK: modelcontextprotocol/typescript-sdk#1957
iss，且仅当服务器声明支持时才会在缺失该参数时拒绝。