令牌受众绑定与验证
RFC 8707 资源指示器通过将令牌绑定到其预期受众，可提供关键的安全收益，前提是授权服务器支持该能力。为促进当前及未来的采用：- MCP 客户端必须在授权和令牌请求中包含
resource参数，具体见 资源参数实现 部分 - MCP 服务器必须验证提交给它们的令牌是专门为其用途签发的
令牌窃取
攻击者如果获取了客户端存储的令牌，或服务器缓存或记录的令牌，就可以通过看似合法的请求访问受保护资源。 客户端和服务器必须实施安全的令牌存储，并遵循 OAuth 最佳实践，如 OAuth 2.1 第 7.1 节 所述。 授权服务器应当签发短期有效的访问令牌，以降低令牌泄露的影响。对于公共客户端，授权服务器必须按照 OAuth 2.1 第 4.3.1 节“令牌端点扩展” 的描述轮换刷新令牌。通信安全
实现必须遵循 OAuth 2.1 第 1.5 节“通信安全”。 具体而言：- 所有授权服务器端点必须通过 HTTPS 提供服务。
- 所有重定向 URI必须是
localhost或使用 HTTPS。
授权码保护
攻击者如果获取了授权响应中包含的授权码，可以尝试用该授权码兑换访问令牌，或以其他方式利用该授权码。 （详见 OAuth 2.1 第 7.5 节） 为缓解这一风险，MCP 客户端必须按照 OAuth 2.1 第 7.5.2 节 实现 PKCE，并且在继续授权前必须验证 PKCE 支持。 PKCE 通过要求客户端创建一对秘密的 verifier-challenge，从而帮助防止授权码拦截和注入攻击，确保只有原始请求方才能将授权码兑换为令牌。 当技术上可行时，MCP 客户端必须使用S256 代码挑战方法，正如 OAuth 2.1 第 4.1.1 节 所要求的那样。
由于 OAuth 2.1 和 PKCE 规范没有定义客户端发现 PKCE 支持的机制，MCP 客户端必须依赖授权服务器元数据来验证此能力：
-
OAuth 2.0 授权服务器元数据：如果缺少
code_challenge_methods_supported，则表示授权服务器不支持 PKCE，MCP 客户端必须拒绝继续。 -
OpenID Connect Discovery 1.0：虽然 OpenID 提供方元数据 没有定义
code_challenge_methods_supported，但 OpenID 提供方通常会包含此字段。MCP 客户端必须在提供方元数据响应中验证code_challenge_methods_supported的存在。如果该字段缺失，MCP 客户端必须拒绝继续。
code_challenge_methods_supported，以确保与 MCP 兼容。
混淆攻击
MCP 客户端在其生命周期内通常会与多个授权服务器交互。控制其中某个授权服务器的攻击者，可能试图让客户端向其发送由另一个诚实授权服务器签发的授权码或令牌（即混淆攻击，见 RFC9207 第 1 节）。 授权响应验证 通过将响应绑定到客户端在重定向前记录的授权服务器来缓解这一问题，因此授权码无法在非预期的令牌端点兑换。仅靠 PKCE 无法阻止此攻击，因为客户端会将code_verifier 发送到攻击者的令牌端点。当攻击者的授权服务器在请求到达诚实授权服务器之前拦截它们时，资源指示器也无济于事。此缓解措施依赖诚实授权服务器发出 iss；对于不发出 iss 的诚实服务器，它不提供保护。
开放重定向
攻击者可能伪造恶意重定向 URI，将用户引导至钓鱼网站。 MCP 客户端必须在授权服务器上注册重定向 URI。 授权服务器必须将实际重定向 URI 与预注册值进行精确匹配验证，以防止重定向攻击。 MCP 客户端应当在授权码流程中使用并验证 state 参数，并丢弃任何未包含原始 state 或与原始 state 不匹配的结果。 授权服务器必须采取预防措施，防止将用户代理重定向到不受信任的 URI，遵循 OAuth 2.1 第 7.12.2 节 中的建议。 如果授权服务器信任该重定向 URI，应当只自动重定向用户代理。如果该 URI 不受信任，授权服务器可以通知用户，并依赖用户作出正确决定。客户端 ID 元数据文档安全性
在实现 客户端 ID 元数据文档 时，授权服务器必须考虑 OAuth 客户端 ID 元数据文档，第 6 节 中详细说明的安全影响。 关键考虑包括：授权服务器滥用防护
授权服务器从未知客户端接收一个 URL 作为输入，并获取该 URL。 恶意客户端可能利用这一点诱使授权服务器向任意 URL 发起请求，例如访问授权服务器有权限访问的私有管理端点。 获取元数据文档的授权服务器应当考虑 服务器端请求伪造（SSRF） 风险，如 OAuth 客户端 ID 元数据文档：服务器端请求伪造（SSRF）攻击 所述。localhost 重定向 URI 风险
客户端 ID 元数据文档本身无法防止localhost URL 冒充。攻击者可以通过以下方式冒充任何客户端：
- 提供合法客户端的元数据 URL 作为其
client_id - 绑定到任意
localhost端口，并将该地址作为 redirect_uri 提供 - 在用户批准后，通过重定向接收授权码
- 应当为仅限
localhost的重定向 URI 显示额外警告 - 可以要求额外的证明机制以增强安全性
- 必须在授权期间清楚显示重定向 URI 的主机名
信任策略
授权服务器可以实施基于域的信任策略：- 受信任域的允许名单（适用于受保护服务器）
- 接受任意 HTTPS
client_id（适用于开放服务器） - 对未知域进行信誉检查
- 基于域年龄或证书验证的限制
- 突出显示 CIMD 和其他相关客户端主机名，以防止钓鱼
受困代理问题
攻击者可以利用充当第三方 API 中介的 MCP 服务器，导致 受困代理漏洞。 通过使用窃取的授权码，他们可以在未经用户同意的情况下获取访问令牌。 使用静态客户端 ID 的 MCP 代理服务器必须在转发到第三方授权服务器之前，为每个 动态注册客户端 获取用户同意（第三方授权服务器可能还需要额外同意）。访问令牌权限限制
如果服务器接受为其他资源签发的令牌，攻击者可能获得未授权访问，或以其他方式危害 MCP 服务器。 此漏洞有两个关键方面：- 受众验证失败。 当 MCP 服务器未验证令牌是否专门面向它（例如通过 RFC9068 中提到的 audience 声明）时，它可能接受最初为其他服务签发的令牌。这破坏了 OAuth 的基本安全边界，使攻击者能够跨不同服务重用本不应这样使用的合法令牌。
- 令牌透传。 如果 MCP 服务器不仅接受受众不正确的令牌，还将这些未修改的令牌转发给下游服务，则可能引发 “受困代理”问题，即下游 API 可能错误地将该令牌视为来自 MCP 服务器，或假定该令牌已被上游 API 验证。有关更多细节，请参见安全最佳实践指南中的 令牌透传部分。
resource 参数，以明确指定请求令牌所针对的目标资源。此要求与 RFC 9728 第 7.4 节 的建议一致。这可确保访问令牌与其预期资源绑定，并且不能跨不同服务被滥用。