授权安全注意事项
社区译文；来源： MCP 80041ab0
本文概述实现者在构建 MCP 客户端和服务器时 MUST 考虑的安全要求。
此外，实现者 MUST 遵循 OAuth 2.1 第 7 节“Security Considerations”中概述的 OAuth 2.1 安全最佳实践。
令牌受众绑定与验证
RFC 8707 Resource Indicators 在授权服务器支持该能力时，通过将令牌绑定到其预期受众来提供关键安全保障。为支持当前及未来采用该能力：
- MCP 客户端 MUST 按照资源参数实现一节的规定，在授权请求和令牌请求中包含
resource参数 - MCP 服务器 MUST 验证提交给它们的令牌确实是专门为其签发的
安全最佳实践（英文）说明了令牌受众验证为何至关重要，以及为何明确禁止令牌透传。
令牌窃取
攻击者一旦获得客户端存储的令牌，或服务器缓存、记录的令牌，就能通过在资源服务器看来合法的请求访问受保护资源。
客户端和服务器 MUST 实现安全的令牌存储，并遵循 OAuth 2.1 第 7.1 节概述的 OAuth 最佳实践。
授权服务器 SHOULD 签发短期访问令牌，以降低令牌泄露的影响。对于公共客户端，授权服务器 MUST 按照 OAuth 2.1 第 4.3.1 节“Token Endpoint Extension”的说明轮换刷新令牌。
通信安全
实现 MUST 遵循 OAuth 2.1 第 1.5 节“Communication Security”。
具体而言：
- 所有授权服务器端点 MUST 通过 HTTPS 提供。
- 所有 redirect URI MUST 使用
localhost或 HTTPS。
授权码保护
能够访问授权响应中授权码的攻击者，可能尝试用该授权码换取访问令牌，或以其他方式利用该授权码。（OAuth 2.1 第 7.5 节对此有进一步说明。）
为降低此风险，MCP 客户端 MUST 按照 OAuth 2.1 第 7.5.2 节实现 PKCE，并且在继续授权前 MUST 验证 PKCE 支持。PKCE 要求客户端创建保密的 verifier-challenge 对，确保只有原始请求方能够用授权码交换令牌，从而帮助防止授权码拦截和注入攻击。
按照 OAuth 2.1 第 4.1.1 节的要求，MCP 客户端在技术条件允许时 MUST 使用 S256 code challenge method。
由于 OAuth 2.1 和 PKCE 规范都未定义客户端发现 PKCE 支持的机制，MCP 客户端 MUST 依赖授权服务器元数据验证该能力：
OAuth 2.0 Authorization Server Metadata：如果缺少
code_challenge_methods_supported，则授权服务器不支持 PKCE，MCP 客户端 MUST 拒绝继续。OpenID Connect Discovery 1.0：尽管 OpenID Provider Metadata 未定义
code_challenge_methods_supported，OpenID 提供方通常会包含此字段。MCP 客户端 MUST 验证提供方元数据响应中是否存在code_challenge_methods_supported。如果该字段缺失，MCP 客户端 MUST 拒绝继续。
提供 OpenID Connect Discovery 1.0 的授权服务器 MUST 在元数据中包含 code_challenge_methods_supported，以确保 MCP 兼容性。
Mix-Up 攻击
控制 MCP 客户端所交互授权服务器之一的攻击者，可能试图让客户端向其发送由另一个可信授权服务器签发的授权码或令牌（即 mix-up 攻击，参见 RFC9207 第 1 节）。授权响应验证规定了必要的缓解措施。
开放重定向
攻击者可能构造恶意 redirect URI，将用户导向钓鱼站点。
MCP 客户端 MUST 在授权服务器中注册 redirect URI。
授权服务器 MUST 对照预注册值精确验证 redirect URI，以防止重定向攻击。
MCP 客户端在授权码流程中 SHOULD 使用并验证 state 参数，并丢弃不包含原始 state 或与原始 state 不匹配的任何结果。
授权服务器 MUST 采取预防措施，避免将用户代理重定向到不受信任的 URI，并遵循 OAuth 2.1 第 7.12.2 节提出的建议。
授权服务器仅在信任重定向 URI 时 SHOULD 自动重定向用户代理。如果该 URI 不受信任，授权服务器 MAY 告知用户，并由用户作出正确决定。
Client ID Metadata Document 安全性
实现 Client ID Metadata Documents 时，授权服务器 MUST 考虑 OAuth Client ID Metadata Document 第 6 节详述的安全影响。主要注意事项包括：
授权服务器滥用防护
获取元数据文档的授权服务器 SHOULD 考虑服务器端请求伪造（SSRF）风险，具体参见 OAuth Client ID Metadata Document: Server Side Request Forgery (SSRF) Attacks。
Localhost Redirect URI 风险
Client ID Metadata Documents 本身无法防止 localhost URL 冒充。
授权服务器：
- 对仅使用
localhost的 redirect URI，SHOULD 显示额外警告 - 为增强安全性，MAY 要求附加证明机制
- 授权期间 MUST 清晰显示 redirect URI 的主机名
信任策略
授权服务器 MAY 实现基于域名的信任策略，用于决定是否接受 Client ID Metadata Documents，具体参见 Client ID Metadata Document 规范的第 6.4 节和第 6.8 节。
Confused Deputy 问题
攻击者可以利用充当第三方 API 中间方的 MCP 服务器，引发 confused deputy 漏洞（英文）。攻击者可以利用窃取的授权码，在未经用户同意的情况下获取访问令牌。
使用静态 client ID 的 MCP 代理服务器，在向第三方授权服务器转发请求之前，MUST 针对每个动态注册客户端取得用户同意（这可能需要额外的同意步骤）。
访问令牌权限限制
如果服务器接受为其他资源签发的令牌，攻击者就可能未经授权访问 MCP 服务器，或以其他方式破坏该服务器。
MCP 服务器 MUST 在处理请求前验证访问令牌，确保访问令牌专门为该 MCP 服务器签发，并采取一切必要措施，确保不会向未授权方返回任何数据。
MCP 服务器 MUST 遵循 OAuth 2.1 第 5.2 节的指导来验证入站令牌。
MCP 服务器 MUST 仅接受专门用于自身的令牌，并且 MUST 拒绝未在 audience claim 中包含自身，或无法通过其他方式确认自身为预期接收方的令牌。详情请参阅安全最佳实践中的令牌透传一节（英文）。
如果 MCP 服务器向上游 API 发出请求，它可以作为这些 API 的 OAuth 客户端。用于上游 API 的访问令牌是由上游授权服务器签发的独立令牌。MCP 服务器 MUST NOT 透传从 MCP 客户端收到的令牌。
MCP 客户端 MUST 实现并使用 RFC 8707 - Resource Indicators for OAuth 2.0 中定义的 resource 参数，以明确指定请求令牌所针对的目标资源。该要求与 RFC 9728 第 7.4 节的建议一致。这可确保访问令牌与其预期资源绑定，不能被跨服务滥用。