MCP 2026-07-28 授权：签发方检查与客户端注册的变化

是什么

本文反映截至 2026年10月25日的情况。2026-07-28 的授权变化涉及签发方验证、注册和凭据归属。上线前，应重新核对相应版本的授权规范、注册规则和授权服务器元数据。客户端 ID 元数据文档（CIMD）并非在此版本首次引入：2025-11-25 变更日志就已推荐使用它。新修订版正式弃用了动态客户端注册（DCR），但为兼容性仍予以保留。

MCP 服务器是受保护资源，MCP 客户端负责获取访问权限，授权服务器则签发令牌。因此，即使这些服务由同一运维方管理，变更也可能需要在不同服务中实施。MCP 的 OAuth 框架适用于 HTTP 部署；它并不是 stdio 所规定的凭据机制。

为什么重要

授权流程必须始终关联到流程开始时选定的签发方。否则，端点变化或含义不明确的注册记录，可能导致凭据被用于错误的授权服务器。CIMD 还带来了获取文档和验证重定向的责任；识别出 URL 形式的客户端标识符，并不意味着应用值得信任。

如何应用

• **在用授权码换取令牌前验证授权响应。**客户端应从已验证的服务器元数据中记录签发方，并将其与本次授权尝试的 PKCE 校验值一起保存。授权服务器应返回 iss，返回时必须声明支持该参数。客户端应在表单解码后，将返回的任何 iss 与记录值进行精确比较，不进行 URL 规范化。值不匹配时必须拒绝，即使收到的是错误响应也一样。如果元数据声明支持签发方参数，却没有 iss，则拒绝；如果既未声明支持，也未提供该参数，规范允许继续。
• **将注册凭据绑定到签发方。**持久化预注册凭据或 DCR 凭据时，以签发服务器的标识符归档。绝不能在另一个签发方处复用这些凭据。应为新服务器获取注册信息；如果预注册信息不匹配，则明确报错。此规则并不意味着自行托管的 CIMD 标识符必须绑定到特定签发方：注册规范明确允许该 URL 标识符在无需重新注册的情况下跨签发方使用。
• **遵循注册方式选择规则。**优先使用可用的预注册信息，其次是在通过 client_id_metadata_document_supported 声明支持时使用 CIMD，最后才使用受支持的 DCR 作为兼容回退。CIMD 文档使用带路径的 HTTPS URL，并包含 client_id、client_name 和 redirect_uris。其 client_id 必须等于该文档的 URL；应验证 JSON，并对照文档验证请求使用的重定向地址。
• **加固元数据获取流程。**获取客户端文档时，应用文档中规定的服务器端请求伪造防护措施。考虑使用域名信任策略。单靠 CIMD 无法防止涉及 localhost 重定向的冒充；应按要求在授权过程中显示重定向主机名。
• **确保旧版 DCR 仍正确运行。**客户端必须指定适当的 application_type。原生桌面、CLI 和 localhost 应用应使用 native；远程浏览器应用应使用 web。应调查注册失败的原因，而不是放宽重定向检查来消除报错。
• **保留现有安全底线。**在元数据中确认 PKCE 支持，保护已存储令牌，并验证收到的令牌确实用于此 MCP 资源。上游 API 调用需要使用单独签发的上游令牌。注册方式迁移不允许直接透传令牌，也不允许移除同意检查。

常见陷阱

不要将 DCR 描述为已移除，也不要说 CIMD 在所有情况下都是强制要求：支持它属于建议。建议在预发布环境执行以下验收测试：签发方响应正确、不匹配和缺失的情况，签发方变更，以及每条保留的注册路径。检查被拒绝的响应绝不会进入授权码兑换步骤。这些检查针对协议符合性，并不构成对某个具体授权部署的安全审计。