> ## Documentation Index
> Fetch the complete documentation index at: https://mcp.developerdoc.cn/llms.txt
> Use this file to discover all available pages before exploring further.

# 授权安全注意事项

<div id="enable-section-numbers" />

本文档概述实现者在构建 MCP 客户端和服务器时 **MUST** 考虑的安全要求。

此外，实现者 **MUST** 遵循 [OAuth 2.1 Section 7. "Security Considerations"](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#name-security-considerations) 中概述的 OAuth 2.1 安全最佳实践。

## Token Audience Binding and Validation

[RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) Resource Indicators 通过将令牌绑定到其预期受众来提供关键安全收益，前提是 **授权服务器支持该能力**。为支持当前和未来的采用：

* MCP 客户端 **MUST** 按照 [resource 参数实现](/specification/draft/basic/authorization#resource-parameter-implementation)部分的规定，在授权请求和令牌请求中包含 `resource` 参数
* MCP 服务器 **MUST** 验证提交给它们的令牌是专门为其使用而颁发的

[Security Best Practices 文档](/docs/tutorials/security/security_best_practices#token-passthrough)概述了为什么令牌受众验证至关重要，以及为什么明确禁止令牌透传。

## Token Theft

攻击者如果获得客户端存储的令牌，或服务器上缓存或记录的令牌，就可以通过对资源服务器看似合法的请求访问受保护资源。

客户端和服务器 **MUST** 实现安全的令牌存储，并遵循 [OAuth 2.1, Section 7.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-7.1) 中概述的 OAuth 最佳实践。

授权服务器 **SHOULD** 颁发短生命周期访问令牌，以降低令牌泄露的影响。对于公共客户端，授权服务器 **MUST** 按照 [OAuth 2.1 Section 4.3.1 "Token Endpoint Extension"](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-4.3.1) 中的描述轮换刷新令牌。

## Communication Security

实现 **MUST** 遵循 [OAuth 2.1 Section 1.5 "Communication Security"](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-1.5)。

具体而言：

1. 所有授权服务器端点 **MUST** 通过 HTTPS 提供服务。
2. 所有重定向 URI **MUST** 是 `localhost` 或使用 HTTPS。

## Authorization Code Protection

获得授权响应中授权码的攻击者可以尝试将该授权码兑换为访问令牌，或以其他方式利用该授权码。（进一步说明见 [OAuth 2.1 Section 7.5](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-7.5)）

为缓解这一风险，MCP 客户端 **MUST** 根据 [OAuth 2.1 Section 7.5.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-7.5.2) 实现 PKCE，并且在继续授权之前 **MUST** 验证 PKCE 支持。PKCE 要求客户端创建秘密的 verifier-challenge 对，从而帮助防止授权码拦截和注入攻击，确保只有原始请求方才能将授权码兑换为令牌。

在技术上可行时，MCP 客户端 **MUST** 按照 [OAuth 2.1 Section 4.1.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#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](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata) 未定义 `code_challenge_methods_supported`，但 OpenID provider 通常会包含此字段。MCP 客户端 **MUST** 验证 provider metadata 响应中存在 `code_challenge_methods_supported`。如果该字段缺失，MCP 客户端 **MUST** 拒绝继续。

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

## Mix-Up Attacks

MCP 客户端在其生命周期内通常会与许多授权服务器交互。控制其中某个授权服务器的攻击者可能试图让客户端向其发送由另一个诚实授权服务器颁发的授权码或令牌（即 mix-up attack，见 [RFC9207 Section 1](https://datatracker.ietf.org/doc/html/rfc9207#section-1)）。

[授权响应验证](/specification/draft/basic/authorization#authorization-response-validation)通过将响应绑定到客户端在重定向前记录的授权服务器来缓解此问题，因此授权码无法在非预期的令牌端点兑换。仅靠 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](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-7.12.2) 中提出的建议。

授权服务器只有在信任重定向 URI 时才 **SHOULD** 自动重定向用户代理。如果 URI 不受信任，授权服务器 MAY 告知用户，并依赖用户做出正确决定。

## Client ID Metadata Document Security

实现 [Client ID Metadata Documents](/specification/draft/basic/authorization/client-registration#client-id-metadata-documents) 时，授权服务器 **MUST** 考虑 [OAuth Client ID Metadata Document, Section 6](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00#name-security-considerations) 中详述的安全影响。关键注意事项包括：

### Authorization Server Abuse Protection

授权服务器会从未知客户端接收 URL 作为输入并获取该 URL。恶意客户端可利用这一点触发授权服务器向任意 URL 发起请求，例如请求授权服务器可访问的私有管理端点。

获取元数据文档的授权服务器 **SHOULD** 考虑 [Server-Side Request Forgery (SSRF)](https://developer.mozilla.org/docs/Web/Security/Attacks/SSRF) 风险，如 [OAuth Client ID Metadata Document: Server Side Request Forgery (SSRF) Attacks](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00#name-server-side-request-forgery) 中所述。

### Localhost Redirect URI Risks

Client ID Metadata Documents 本身无法防止 `localhost` URL 冒充。攻击者可以通过以下方式声称自己是任何客户端：

1. 将合法客户端的元数据 URL 作为其 `client_id`
2. 绑定到任意 `localhost` 端口，并将该地址作为 redirect\_uri 提供
3. 在用户批准后，通过重定向接收授权码

服务器会看到合法客户端的元数据文档，用户也会看到合法客户端的名称，从而使攻击难以发现。

授权服务器：

* **SHOULD** 对仅使用 `localhost` 的重定向 URI 显示额外警告
* **MAY** 要求额外的证明机制以增强安全性
* **MUST** 在授权期间清楚显示重定向 URI 主机名

### Trust Policies

授权服务器 **MAY** 实现基于域的信任策略：

* 受信任域的允许列表（用于受保护服务器）
* 接受任何 HTTPS `client_id`（用于开放服务器）
* 对未知域进行信誉检查
* 基于域名年龄或证书验证的限制
* 突出显示 CIMD 和其他关联的客户端主机名，以防止钓鱼

服务器对其访问策略保持完全控制。

## Confused Deputy Problem

攻击者可以利用充当第三方 API 中介的 MCP 服务器，导致 [confused deputy 漏洞](/docs/tutorials/security/security_best_practices#confused-deputy-problem)。通过使用窃取的授权码，他们可以在未经用户同意的情况下获取访问令牌。

使用静态客户端 ID 的 MCP 代理服务器在转发到第三方授权服务器之前，**MUST** 为每个[动态注册客户端](/specification/draft/basic/authorization/client-registration#dynamic-client-registration)取得用户同意（这可能需要额外同意）。

## Access Token Privilege Restriction

如果服务器接受为其他资源颁发的令牌，攻击者可能获得未授权访问，或以其他方式危害 MCP 服务器。

此漏洞有两个关键维度：

1. **受众验证失败。** 当 MCP 服务器未验证令牌是否专门以其为目标（例如通过 [RFC9068](https://www.rfc-editor.org/rfc/rfc9068.html) 中提到的 audience claim）时，它可能接受原本为其他服务颁发的令牌。这会破坏基本的 OAuth 安全边界，使攻击者能够在非预期的不同服务之间复用合法令牌。
2. **令牌透传。** 如果 MCP 服务器不仅接受受众不正确的令牌，还将这些未经修改的令牌转发给下游服务，则可能导致 ["confused deputy" 问题](#confused-deputy-problem)：下游 API 可能错误地信任该令牌，仿佛它来自 MCP 服务器，或假定该令牌已由上游 API 验证。更多详细信息请参见 Security Best Practices 指南中的[令牌透传部分](/docs/tutorials/security/security_best_practices#token-passthrough)。

MCP 服务器 **MUST** 在处理请求之前验证访问令牌，确保访问令牌是专门为该 MCP 服务器颁发的，并采取所有必要步骤，确保不会向未授权方返回任何数据。

MCP 服务器 **MUST** 遵循 [OAuth 2.1 - Section 5.2](https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-13.html#section-5.2) 中的指导原则来验证入站令牌。

MCP 服务器 **MUST** 只接受专门以自身为目标的令牌，并且 **MUST** 拒绝未在 audience claim 中包含自身的令牌，或通过其他方式验证自己是该令牌预期接收方。详情请参见 [Security Best Practices 的令牌透传部分](/docs/tutorials/security/security_best_practices#token-passthrough)。

如果 MCP 服务器向上游 API 发起请求，它可以作为这些 API 的 OAuth 客户端。上游 API 使用的访问令牌是由上游授权服务器颁发的独立令牌。MCP 服务器 **MUST NOT** 透传它从 MCP 客户端收到的令牌。

MCP 客户端 **MUST** 实现并使用 [RFC 8707 - Resource Indicators for OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8707.html) 中定义的 `resource` 参数，以显式指定正在为其请求令牌的目标资源。此要求与 [RFC 9728 Section 7.4](https://datatracker.ietf.org/doc/html/rfc9728#section-7.4) 中的建议一致。这确保访问令牌绑定到其预期资源，且不能在不同服务之间被滥用。