令牌受众绑定与验证
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 兼容。
混淆攻击
An attacker that controls one of the authorization servers an MCP client interacts with may attempt to have the client send it an authorization code or token issued by a different, honest authorization server (a mix-up attack, described in RFC9207 Section 1). Authorization Response Validation specifies the required mitigation.开放重定向
攻击者可能伪造恶意重定向 URI，将用户引导至钓鱼网站。 MCP 客户端必须在授权服务器上注册重定向 URI。 授权服务器必须将实际重定向 URI 与预注册值进行精确匹配验证，以防止重定向攻击。 MCP 客户端应当在授权码流程中使用并验证 state 参数，并丢弃任何未包含原始 state 或与原始 state 不匹配的结果。 授权服务器必须采取预防措施，防止将用户代理重定向到不受信任的 URI，遵循 OAuth 2.1 第 7.12.2 节 中的建议。 如果授权服务器信任该重定向 URI，应当只自动重定向用户代理。如果该 URI 不受信任，授权服务器可以通知用户，并依赖用户作出正确决定。客户端 ID 元数据文档安全性
在实现 客户端 ID 元数据文档 时，授权服务器必须考虑 OAuth 客户端 ID 元数据文档，第 6 节 中详细说明的安全影响。 关键考虑包括：授权服务器滥用防护
Authorization servers fetching metadata documents SHOULD consider Server-Side Request Forgery (SSRF) risks, as described in OAuth Client ID Metadata Document: Server Side Request Forgery (SSRF) Attacks.localhost 重定向 URI 风险
Client ID Metadata Documents cannot preventlocalhost URL impersonation by themselves.
授权服务器：
- 应当为仅限
localhost的重定向 URI 显示额外警告 - 可以要求额外的证明机制以增强安全性
- 必须在授权期间清楚显示重定向 URI 的主机名
信任策略
Authorization servers MAY implement domain-based trust policies for accepting Client ID Metadata Documents, as described in Section 6.4 and Section 6.8 of the Client ID Metadata Document specification.受困代理问题
Attackers can exploit MCP servers acting as intermediaries to third-party APIs, leading to confused deputy vulnerabilities. By using stolen authorization codes, they can obtain access tokens without user consent. 使用静态客户端 ID 的 MCP 代理服务器必须在转发到第三方授权服务器之前，为每个 动态注册客户端 获取用户同意（第三方授权服务器可能还需要额外同意）。访问令牌权限限制
如果服务器接受为其他资源签发的令牌，攻击者可能获得未授权访问，或以其他方式危害 MCP 服务器。 MCP servers MUST validate access tokens before processing the request, ensuring the access token is issued specifically for the MCP server, and take all necessary steps to ensure no data is returned to unauthorized parties. MCP 服务器必须遵循 OAuth 2.1 - 第 5.2 节 中的指南来验证传入令牌。 MCP servers MUST only accept tokens specifically intended for themselves and MUST reject tokens that do not include them in the audience claim or otherwise verify that they are the intended recipient of the token. See the Security Best Practices Token Passthrough section for details. 如果 MCP 服务器向上游 API 发起请求，它可能会作为这些 API 的 OAuth 客户端。上游 API 使用的访问令牌是单独的令牌，由上游授权服务器签发。MCP 服务器不得透传其从 MCP 客户端收到的令牌。 MCP 客户端必须实现并使用 RFC 8707 - OAuth 2.0 的资源指示器 中定义的resource 参数，以明确指定请求令牌所针对的目标资源。此要求与 RFC 9728 第 7.4 节 的建议一致。这可确保访问令牌与其预期资源绑定，并且不能跨不同服务被滥用。