授权安全注意事项

本文档概述了实现者在构建 MCP 客户端(连接器)和服务端时MUST（必须）考虑的安全要求。

此外，实现者MUST（必须）遵循 OAuth 2.1 第 7 节 "安全注意事项" 中概述的 OAuth 2.1 安全最佳实践。

Token 受众绑定与验证

RFC 8707 资源指示器通过将 token 绑定到其预期受众，在授权服务器支持该能力时提供了关键的安全优势。为支持当前和未来的采用：

MCP 客户端(连接器) MUST（必须）在授权和 token 请求中包含 resource 参数，如资源参数实现部分所述
MCP 服务端 MUST（必须）验证呈现给它们的 token 是专门为其使用而签发的

安全最佳实践文档概述了为什么 token 受众验证至关重要，以及为什么 Token 透传被明确禁止。

Token 窃取

获取了客户端存储的 token，或服务端缓存或记录的 token 的攻击者，可以使用对资源服务器而言看似合法的请求访问受保护资源。

客户端(连接器)和服务端 MUST（必须）实现安全的 token 存储并遵循 OAuth 最佳实践，如 OAuth 2.1 第 7.1 节所述。

授权服务器 SHOULD（应）签发短期访问 token 以减少泄露 token 的影响。对于公共客户端，授权服务器 MUST（必须）按照 OAuth 2.1 第 4.3.1 节 "Token 端点扩展"所述轮换刷新 token。

通信安全

实现 MUST（必须）遵循 OAuth 2.1 第 1.5 节 "通信安全"。

具体而言：

所有授权服务器端点 MUST（必须）通过 HTTPS 提供服务。
所有重定向 URI MUST（必须）为 localhost 或使用 HTTPS。

授权码保护

获得了授权响应中包含的授权码的攻击者，可以尝试用该授权码兑换访问 token，或以其他方式利用该授权码。（在 OAuth 2.1 第 7.5 节中有进一步描述）

为缓解此问题，MCP 客户端(连接器) MUST（必须）按照 OAuth 2.1 第 7.5.2 节实现 PKCE，并且MUST（必须）在继续授权之前验证 PKCE 支持。 PKCE 通过要求客户端创建秘密的 verifier-challenge 对，确保只有原始请求方才能用授权码兑换 token，从而帮助防止授权码拦截和注入攻击。

MCP 客户端(连接器) MUST（必须）在技术上可行时使用 S256 code challenge 方法，如 OAuth 2.1 第 4.1.1 节所要求。

由于 OAuth 2.1 和 PKCE 规范未定义客户端发现 PKCE 支持的机制，MCP 客户端(连接器) MUST（必须）依赖授权服务器元数据来验证此能力：

OAuth 2.0 授权服务器元数据：如果 code_challenge_methods_supported 缺失，则授权服务器不支持 PKCE，MCP 客户端(连接器) MUST（必须）拒绝继续。
OpenID Connect Discovery 1.0：虽然 OpenID Provider 元数据未定义 code_challenge_methods_supported，但 OpenID 提供方通常会包含此字段。MCP 客户端(连接器) MUST（必须）验证提供方元数据响应中存在 code_challenge_methods_supported。如果该字段缺失，MCP 客户端(连接器) MUST（必须）拒绝继续。

提供 OpenID Connect Discovery 1.0 的授权服务器 MUST（必须）在其元数据中包含 code_challenge_methods_supported，以确保 MCP 兼容性。

混淆攻击

控制了 MCP 客户端(连接器)所交互的某个授权服务器的攻击者，可能试图让客户端向其发送由另一个诚实的授权服务器签发的授权码或 token（一种混淆攻击，描述于 RFC9207 第 1 节）。授权响应验证规定了所需的缓解措施。

开放重定向

攻击者可能构造恶意重定向 URI 将用户引导至钓鱼网站。

MCP 客户端(连接器) MUST（必须）在授权服务器注册重定向 URI。

授权服务器 MUST（必须）针对预注册值验证精确的重定向 URI，以防止重定向攻击。

MCP 客户端(连接器) SHOULD（应）在授权码流程中使用并验证 state 参数，并丢弃任何不包含原始 state 或与其不匹配的结果。

授权服务器 MUST（必须）采取预防措施，防止将用户代理重定向到不受信任的 URI，遵循 OAuth 2.1 第 7.12.2 节中提出的建议

授权服务器 SHOULD（应）仅在其信任重定向 URI 时才自动重定向用户代理。如果该 URI 不受信任，授权服务器 MAY（可以）告知用户并依赖用户做出正确的决定。

客户端 ID 元数据文档安全

在实现客户端 ID 元数据文档时，授权服务器 MUST（必须）考虑 OAuth Client ID Metadata Document, Section 6 中详述的安全影响。关键考虑因素包括：

授权服务器滥用防护

获取元数据文档的授权服务器 SHOULD（应该）考虑服务端请求伪造 (SSRF) 风险，如 OAuth Client ID Metadata Document: Server Side Request Forgery (SSRF) Attacks 所述。

Localhost 重定向 URI 风险

客户端 ID 元数据文档本身无法防止 localhost URL 冒充。

授权服务器：

SHOULD（应该）对仅使用 localhost 的重定向 URI 显示额外警告
MAY（可以）要求额外的证明机制以增强安全性
MUST（必须）在授权期间清晰显示重定向 URI 的主机名

信任策略

授权服务器 MAY（可以）实施基于域的信任策略以接受客户端 ID 元数据文档，如客户端 ID 元数据文档规范的 Section 6.4 和 Section 6.8 所述。

混淆代理问题

攻击者可以利用充当第三方 API 中间人的 MCP 服务端，导致混淆代理漏洞。通过使用窃取的授权码，他们可以在未经用户同意的情况下获取访问令牌。

使用静态客户端 ID 的 MCP 代理服务器 MUST（必须）在转发到第三方授权服务器（这可能需要额外同意）之前，为每个动态注册的客户端获取用户同意。

访问令牌权限限制

如果 MCP 服务端接受为其他资源签发的令牌，攻击者就可以获得未经授权的访问或以其他方式入侵 MCP 服务端。

MCP 服务端 MUST（必须）在处理请求之前验证访问令牌，确保访问令牌是专门为 MCP 服务端签发的，并采取一切必要步骤确保不会向未经授权的方返回任何数据。

MCP 服务端 MUST（必须）遵循 OAuth 2.1 - Section 5.2 中的指南来验证入站令牌。

MCP 服务端 MUST（必须）仅接受专门为其自身准备的令牌，并且 MUST（必须）拒绝未在 audience claim 中包含自身的令牌，或以其他方式验证自身是该令牌的预期接收者。详情请参阅安全最佳实践 Token 透传部分。

如果 MCP 服务端向上游 API 发起请求，它可能作为这些 API 的 OAuth 客户端。在上游 API 使用的访问令牌是由上游授权服务器签发的单独令牌。MCP 服务端 MUST NOT（不得）透传它从 MCP 客户端收到的令牌。

MCP 客户端 MUST（必须）实现并使用 RFC 8707 - Resource Indicators for OAuth 2.0 中定义的 resource 参数，以明确指定请求令牌所针对的目标资源。此要求与 RFC 9728 Section 7.4 中的建议一致。这确保访问令牌绑定到其预期资源，并且不能跨不同服务被滥用。