Token Audience Binding and Validation
RFC 8707 Resource Indicators 通过将令牌绑定到其预期受众来提供关键安全收益，前提是 授权服务器支持该能力。为支持当前和未来的采用：- MCP 客户端 MUST 按照 resource 参数实现部分的规定，在授权请求和令牌请求中包含
resource参数 - MCP 服务器 MUST 验证提交给它们的令牌是专门为其使用而颁发的
Token Theft
攻击者如果获得客户端存储的令牌，或服务器上缓存或记录的令牌，就可以通过对资源服务器看似合法的请求访问受保护资源。 客户端和服务器 MUST 实现安全的令牌存储，并遵循 OAuth 2.1, Section 7.1 中概述的 OAuth 最佳实践。 授权服务器 SHOULD 颁发短生命周期访问令牌，以降低令牌泄露的影响。对于公共客户端，授权服务器 MUST 按照 OAuth 2.1 Section 4.3.1 “Token Endpoint Extension” 中的描述轮换刷新令牌。Communication Security
实现 MUST 遵循 OAuth 2.1 Section 1.5 “Communication Security”。 具体而言：- 所有授权服务器端点 MUST 通过 HTTPS 提供服务。
- 所有重定向 URI MUST 是
localhost或使用 HTTPS。
Authorization Code Protection
获得授权响应中授权码的攻击者可以尝试将该授权码兑换为访问令牌，或以其他方式利用该授权码。（进一步说明见 OAuth 2.1 Section 7.5） 为缓解这一风险，MCP 客户端 MUST 根据 OAuth 2.1 Section 7.5.2 实现 PKCE，并且在继续授权之前 MUST 验证 PKCE 支持。PKCE 要求客户端创建秘密的 verifier-challenge 对，从而帮助防止授权码拦截和注入攻击，确保只有原始请求方才能将授权码兑换为令牌。 在技术上可行时，MCP 客户端 MUST 按照 OAuth 2.1 Section 4.1.1 的要求使用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 provider 通常会包含此字段。MCP 客户端 MUST 验证 provider metadata 响应中存在code_challenge_methods_supported。如果该字段缺失，MCP 客户端 MUST 拒绝继续。
code_challenge_methods_supported，以确保 MCP 兼容性。
Mix-Up Attacks
MCP 客户端在其生命周期内通常会与许多授权服务器交互。控制其中某个授权服务器的攻击者可能试图让客户端向其发送由另一个诚实授权服务器颁发的授权码或令牌（即 mix-up attack，见 RFC9207 Section 1）。 授权响应验证通过将响应绑定到客户端在重定向前记录的授权服务器来缓解此问题，因此授权码无法在非预期的令牌端点兑换。仅靠 PKCE 无法防止此攻击，因为客户端会将code_verifier 传输给攻击者的令牌端点。当攻击者的授权服务器在请求到达诚实授权服务器之前拦截请求时，resource indicators 也无济于事。此缓解措施依赖诚实授权服务器发出 iss；对于不发出 iss 的诚实服务器，它不提供保护。
Open Redirection
攻击者可能构造恶意重定向 URI，将用户引导到钓鱼网站。 MCP 客户端 MUST 在授权服务器注册重定向 URI。 授权服务器 MUST 根据预注册值精确验证重定向 URI，以防止重定向攻击。 MCP 客户端 SHOULD 在授权码流程中使用并验证 state 参数，并丢弃任何不包含原始 state 或与原始 state 不匹配的结果。 授权服务器 MUST 采取预防措施，防止将用户代理重定向到不受信任的 URI，并遵循 OAuth 2.1 Section 7.12.2 中提出的建议。 授权服务器只有在信任重定向 URI 时才 SHOULD 自动重定向用户代理。如果 URI 不受信任，授权服务器 MAY 告知用户，并依赖用户做出正确决定。Client ID Metadata Document Security
实现 Client ID Metadata Documents 时，授权服务器 MUST 考虑 OAuth Client ID Metadata Document, Section 6 中详述的安全影响。关键注意事项包括：Authorization Server Abuse Protection
授权服务器会从未知客户端接收 URL 作为输入并获取该 URL。恶意客户端可利用这一点触发授权服务器向任意 URL 发起请求，例如请求授权服务器可访问的私有管理端点。 获取元数据文档的授权服务器 SHOULD 考虑 Server-Side Request Forgery (SSRF) 风险，如 OAuth Client ID Metadata Document: Server Side Request Forgery (SSRF) Attacks 中所述。Localhost Redirect URI Risks
Client ID Metadata Documents 本身无法防止localhost URL 冒充。攻击者可以通过以下方式声称自己是任何客户端：
- 将合法客户端的元数据 URL 作为其
client_id - 绑定到任意
localhost端口，并将该地址作为 redirect_uri 提供 - 在用户批准后，通过重定向接收授权码
- SHOULD 对仅使用
localhost的重定向 URI 显示额外警告 - MAY 要求额外的证明机制以增强安全性
- MUST 在授权期间清楚显示重定向 URI 主机名
Trust Policies
授权服务器 MAY 实现基于域的信任策略：- 受信任域的允许列表（用于受保护服务器）
- 接受任何 HTTPS
client_id（用于开放服务器） - 对未知域进行信誉检查
- 基于域名年龄或证书验证的限制
- 突出显示 CIMD 和其他关联的客户端主机名，以防止钓鱼
Confused Deputy Problem
攻击者可以利用充当第三方 API 中介的 MCP 服务器，导致 confused deputy 漏洞。通过使用窃取的授权码，他们可以在未经用户同意的情况下获取访问令牌。 使用静态客户端 ID 的 MCP 代理服务器在转发到第三方授权服务器之前，MUST 为每个动态注册客户端取得用户同意（这可能需要额外同意）。Access Token Privilege Restriction
如果服务器接受为其他资源颁发的令牌，攻击者可能获得未授权访问，或以其他方式危害 MCP 服务器。 此漏洞有两个关键维度：- 受众验证失败。 当 MCP 服务器未验证令牌是否专门以其为目标（例如通过 RFC9068 中提到的 audience claim）时，它可能接受原本为其他服务颁发的令牌。这会破坏基本的 OAuth 安全边界，使攻击者能够在非预期的不同服务之间复用合法令牌。
- 令牌透传。 如果 MCP 服务器不仅接受受众不正确的令牌，还将这些未经修改的令牌转发给下游服务，则可能导致 “confused deputy” 问题：下游 API 可能错误地信任该令牌，仿佛它来自 MCP 服务器，或假定该令牌已由上游 API 验证。更多详细信息请参见 Security Best Practices 指南中的令牌透传部分。
resource 参数，以显式指定正在为其请求令牌的目标资源。此要求与 RFC 9728 Section 7.4 中的建议一致。这确保访问令牌绑定到其预期资源，且不能在不同服务之间被滥用。