> ## Documentation Index
> Fetch the complete documentation index at: https://mcp.zhcndoc.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 授权
## 引言
### 目的与范围
模型上下文协议（Model Context Protocol）在传输层提供授权能力，
使 MCP 客户端能够代表资源所有者向受限制的 MCP 服务器发出请求。本规范定义了基于 HTTP 的传输的授权流程。
### 协议要求
授权对于 MCP 实现是**可选的**。当支持时：
* 使用基于 HTTP 传输的实现**应**符合本规范。
* 使用 STDIO 传输的实现**不应**遵循本规范，而
应从环境中检索凭证。
* 使用替代传输的实现**必须**遵循其协议既定的安全最佳
实践。
### 标准合规性
此授权机制基于以下列出的既定标准，但
实施了其功能的选定子集，以确保安全性和互操作性
同时保持简单性：
* OAuth 2.1 IETF 草案 ([draft-ietf-oauth-v2-1-13](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13))
* OAuth 2.0 授权服务器元数据
([RFC8414](https://datatracker.ietf.org/doc/html/rfc8414))
* OAuth 2.0 动态客户端注册协议
([RFC7591](https://datatracker.ietf.org/doc/html/rfc7591))
* OAuth 2.0 受保护资源元数据 ([RFC9728](https://datatracker.ietf.org/doc/html/rfc9728))
## 授权流程
### 角色
受保护的 *MCP 服务器* 充当 [OAuth 2.1 资源服务器](https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-13.html#name-roles)，
能够使用访问令牌接受和响应受保护的资源请求。
*MCP 客户端* 充当 [OAuth 2.1 客户端](https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-13.html#name-roles)，
代表资源所有者发出受保护的资源请求。
*授权服务器* 负责与用户交互（如有必要）并为在 MCP 服务器上使用颁发访问令牌。
授权服务器的实现细节超出本规范的范围。它可以与
资源服务器一起托管或作为单独的实体。[授权服务器发现部分](#authorization-server-discovery)
规定了 MCP 服务器如何向客户端指示其对应授权服务器的位置。
### 概述
1. 授权服务器**必须**实施 OAuth 2.1，并具备适当的的安全
措施，适用于机密客户端和公共客户端。
2. 授权服务器和 MCP 客户端**应**支持 OAuth 2.0 动态客户端注册
协议 ([RFC7591](https://datatracker.ietf.org/doc/html/rfc7591))。
3. MCP 服务器**必须**实施 OAuth 2.0 受保护资源元数据 ([RFC9728](https://datatracker.ietf.org/doc/html/rfc9728))。
MCP 客户端**必须**使用 OAuth 2.0 受保护资源元数据进行授权服务器发现。
4. 授权服务器**必须**提供 OAuth 2.0 授权
服务器元数据 ([RFC8414](https://datatracker.ietf.org/doc/html/rfc8414))。
MCP 客户端**必须**使用 OAuth 2.0 授权服务器元数据。
### 授权服务器发现
本节描述了 MCP 服务器向其关联的
授权服务器向 MCP 客户端广告其关联的授权服务器的机制，以及 MCP
客户端可以确定授权服务器端点和支持功能的发现过程。
#### 授权服务器位置
MCP 服务器**必须**实施 OAuth 2.0 受保护资源元数据 ([RFC9728](https://datatracker.ietf.org/doc/html/rfc9728))
规范以指示授权服务器的位置。MCP 服务器返回的受保护资源元数据文档**必须**包含
`authorization_servers` 字段，其中包含至少一个授权服务器。
`authorization_servers` 的具体使用超出本规范的范围；实现者应咨询
OAuth 2.0 受保护资源元数据 ([RFC9728](https://datatracker.ietf.org/doc/html/rfc9728)) 以
获取实现细节的指导。
实现者应注意，受保护资源元数据文档可以定义多个授权服务器。选择使用哪个授权服务器的责任在于 MCP 客户端，遵循
[RFC9728 第 7.6 节“授权服务器"](https://datatracker.ietf.org/doc/html/rfc9728#name-authorization-servers) 中指定的指南。
MCP 服务器在返回 *401 Unauthorized* 时**必须**使用 HTTP 头 `WWW-Authenticate` 来指示资源服务器元数据 URL 的位置，
如 [RFC9728 第 5.1 节"WWW-Authenticate 响应"](https://datatracker.ietf.org/doc/html/rfc9728#name-www-authenticate-response) 中所述。
MCP 客户端**必须**能够解析 `WWW-Authenticate` 头并适当响应来自 MCP 服务器的 `HTTP 401 Unauthorized` 响应。
#### 服务器元数据发现
MCP 客户端**必须**遵循 OAuth 2.0 授权服务器元数据 [RFC8414](https://datatracker.ietf.org/doc/html/rfc8414)
规范以获取与授权服务器交互所需的信息。
#### 序列图
下图概述了一个示例流程：
```mermaid theme={null}
sequenceDiagram
participant C as 客户端
participant M as MCP 服务器 (资源服务器)
participant A as 授权服务器
C->>M: 无令牌的 MCP 请求
M-->>C: 带 WWW-Authenticate 头的 HTTP 401 Unauthorized
Note over C: 从 WWW-Authenticate
提取 resource_metadata
C->>M: GET /.well-known/oauth-protected-resource
M-->>C: 带授权服务器 URL 的资源元数据
Note over C: 验证 RS 元数据，
构建 AS 元数据 URL
C->>A: GET /.well-known/oauth-authorization-server
A-->>C: 授权服务器元数据
Note over C,A: OAuth 2.1 授权流程在此发生
C->>A: 令牌请求
A-->>C: 访问令牌
C->>M: 带访问令牌的 MCP 请求
M-->>C: MCP 响应
Note over C,M: MCP 通信继续使用有效令牌
```
### 动态客户端注册
MCP 客户端和授权服务器**应**支持
OAuth 2.0 动态客户端注册协议 [RFC7591](https://datatracker.ietf.org/doc/html/rfc7591)
以允许 MCP 客户端无需用户交互即可获取 OAuth 客户端 ID。这为客户端提供了一种
标准化的方式以自动注册新的授权服务器，这对
MCP 至关重要，因为：
* 客户端可能无法预先知道所有可能的 MCP 服务器及其授权服务器。
* 手动注册会给用户造成摩擦。
* 它能实现无缝连接到新的 MCP 服务器及其授权服务器。
* 授权服务器可以实现自己的注册策略。
任何\_不\_支持动态客户端注册的授权服务器都需要提供
获取客户端 ID（以及适用的客户端凭证）的替代方式。对于其中一个
授权服务器，MCP 客户端将不得不：
1. 硬编码客户端 ID（以及适用的客户端凭证），专门供 MCP 客户端在与
该授权服务器交互时使用，或
2. 向用户展示 UI，允许他们在自行注册
OAuth 客户端后输入这些详细信息（例如，通过由
服务器托管的配置界面）。
### 授权流程步骤
完整的授权流程如下：
```mermaid theme={null}
sequenceDiagram
participant B as 用户代理 (浏览器)
participant C as 客户端
participant M as MCP 服务器 (资源服务器)
participant A as 授权服务器
C->>M: 无令牌的 MCP 请求
M->>C: 带 WWW-Authenticate 头的 HTTP 401 Unauthorized
Note over C: 从 WWW-Authenticate 提取 resource_metadata URL
C->>M: 请求受保护资源元数据
M->>C: 返回元数据
Note over C: 解析元数据并提取授权服务器
客户端确定要使用的 AS
C->>A: GET /.well-known/oauth-authorization-server
A->>C: 授权服务器元数据响应
alt 动态客户端注册
C->>A: POST /register
A->>C: 客户端凭证
end
Note over C: 生成 PKCE 参数
包含 resource 参数
C->>B: 打开浏览器携带授权 URL + code_challenge + resource
B->>A: 带 resource 参数的授权请求
Note over A: 用户授权
A->>B: 重定向到回调携带授权码
B->>C: 授权码回调
C->>A: 令牌请求 + code_verifier + resource
A->>C: 访问令牌 (+ 刷新令牌)
C->>M: 带访问令牌的 MCP 请求
M-->>C: MCP 响应
Note over C,M: MCP 通信继续使用有效令牌
```
#### 资源参数实现
MCP 客户端**必须**实施 [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) 中定义的 OAuth 2.0 资源指示器
以明确指定请求令牌的目标资源。`resource` 参数：
1. **必须**包含在授权请求和令牌请求中。
2. **必须**标识客户端打算与其一起使用令牌的 MCP 服务器。
3. **必须**使用 [RFC 8707 第 2 节](https://www.rfc-editor.org/rfc/rfc8707.html#name-access-token-request) 中定义的 MCP 服务器的规范 URI。
##### 规范服务器 URI
就本规范而言，MCP 服务器的规范 URI 定义为资源标识符，如
[RFC 8707 第 2 节](https://www.rfc-editor.org/rfc/rfc8707.html#section-2) 中指定，并与
[RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728) 中的 `resource` 参数保持一致。
MCP 客户端**应**为其打算访问的 MCP 服务器提供尽可能具体的 URI，遵循 [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707) 中的指导。虽然规范形式使用小写方案和主机组件，但实现**应**接受大写方案和主机组件以增强健壮性和互操作性。
有效规范 URI 示例：
* `https://mcp.example.com/mcp`
* `https://mcp.example.com`
* `https://mcp.example.com:8443`
* `https://mcp.example.com/server/mcp`（当路径组件对于标识单个 MCP 服务器是必要时）
无效规范 URI 示例：
* `mcp.example.com`（缺少方案）
* `https://mcp.example.com#fragment`（包含片段）
> **注意：** 虽然 `https://mcp.example.com/`（带尾部斜杠）和 `https://mcp.example.com`（不带尾部斜杠）根据 [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986) 在技术上都是有效的绝对 URI，但实现**应**一致地使用不带尾部斜杠的形式以获得更好的互操作性，除非尾部斜杠对于特定资源具有语义意义。
例如，如果访问 `https://mcp.example.com` 处的 MCP 服务器，授权请求将包括：
```
&resource=https%3A%2F%2Fmcp.example.com
```
MCP 客户端**必须**发送此参数，无论授权服务器是否支持它。
### 访问令牌使用
#### 令牌要求
向 MCP 服务器发出请求时的访问令牌处理**必须**符合
[OAuth 2.1 第 5 节“资源请求"](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-5) 中定义的要求。
具体而言：
1. MCP 客户端**必须**使用 [OAuth 2.1 第 5.1.1 节](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-5.1.1) 中定义的授权请求头字段：
```
Authorization: Bearer
```
注意授权**必须**包含在从客户端到服务器的每个 HTTP 请求中，
即使它们是同一逻辑会话的一部分。
2. 访问令牌**不得**包含在 URI 查询字符串中
请求示例：
```http theme={null}
GET /mcp HTTP/1.1
Host: mcp.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
```
#### 令牌处理
MCP 服务器作为 OAuth 2.1 资源服务器，**必须**验证访问令牌，如
[OAuth 2.1 第 5.2 节](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-5.2) 中所述。
MCP 服务器**必须**验证访问令牌是专门为其作为预期受众颁发的，
根据 [RFC 8707 第 2 节](https://www.rfc-editor.org/rfc/rfc8707.html#section-2)。
如果验证失败，服务器**必须**根据
[OAuth 2.1 第 5.3 节](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-5.3)
错误处理要求进行响应。无效或过期的令牌**必须**收到 HTTP 401
响应。
MCP 客户端**不得**向 MCP 服务器发送除 MCP 服务器授权服务器颁发的令牌以外的令牌。
授权服务器**必须**仅接受对其
自有资源有效的令牌。
MCP 服务器**不得**接受或传输任何其他令牌。
### 错误处理
服务器**必须**为授权错误返回适当的 HTTP 状态码：
| 状态码 | 描述 | 用途 |
| --- | ---- | --------- |
| 401 | 未授权 | 需要授权或令牌无效 |
| 403 | 禁止 | 无效范围或权限不足 |
| 400 | 错误请求 | 授权请求格式错误 |
## 安全注意事项
实现 **必须** 遵循 [OAuth 2.1 第 7 节“安全注意事项”](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#name-security-considerations) 中规定的 OAuth 2.1 安全最佳实践。
### 令牌受众绑定和验证
[RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) 资源指示器通过将令牌绑定到其预期受众提供关键的安全益处，**当授权服务器支持该功能时**。为了促进当前和未来的采用：
* MCP 客户端 **必须** 在授权和令牌请求中包含 `resource` 参数，如 [资源参数实现](#resource-parameter-implementation) 部分所述
* MCP 服务器 **必须** 验证呈现给它们的令牌是专门为其使用而颁发的
[安全最佳实践文档](/specification/2025-06-18/basic/security_best_practices#token-passthrough) 概述了为什么令牌受众验证至关重要，以及为什么明确禁止令牌传递。
### 令牌盗窃
获取客户端存储的令牌，或服务器上缓存或记录的令牌的攻击者，可以使用对资源服务器看似合法的请求访问受保护资源。
客户端和服务器 **必须** 实现安全的令牌存储并遵循 OAuth 最佳实践，如 [OAuth 2.1，第 7.1 节](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-7.1) 所述。
授权服务器 **应该** 颁发短寿命访问令牌以减少令牌泄露的影响。
对于公共客户端，授权服务器 **必须** 如 [OAuth 2.1 第 4.3.1 节“令牌端点扩展”](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-4.3.1) 所述轮换刷新令牌。
### 通信安全
实现 **必须** 遵循 [OAuth 2.1 第 1.5 节“通信安全”](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-1.5)。
具体而言：
1. 所有授权服务器端点 **必须** 通过 HTTPS 提供服务。
2. 所有重定向 URI **必须** 是 `localhost` 或使用 HTTPS。
### 授权码保护
获得授权响应中包含的授权码访问权限的攻击者可以尝试兑换授权码以获取访问令牌，或以其他方式利用授权码。（在 [OAuth 2.1 第 7.5 节](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-7.5) 中进一步描述）
为了缓解这种情况，MCP 客户端 **必须** 根据 [OAuth 2.1 第 7.5.2 节](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-7.5.2) 实施 PKCE。
PKCE 通过要求客户端创建秘密验证器 - 质询对，帮助防止授权码拦截和注入攻击，确保只有原始请求者可以将授权码交换为令牌。
### 开放重定向
攻击者可能制作恶意重定向 URI 将用户引导至钓鱼网站。
MCP 客户端 **必须** 在授权服务器注册重定向 URI。
授权服务器 **必须** 针对预注册值验证确切的重定向 URI 以防止重定向攻击。
MCP 客户端 **应该** 在授权码流中使用和验证状态参数，并丢弃任何不包含或与原始状态不匹配的结果。
授权服务器 **必须** 采取预防措施防止将用户代理重定向到不可信的 URI，遵循 [OAuth 2.1 第 7.12.2 节](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-7.12.2) 中提出的建议。
授权服务器 **应该** 仅在信任重定向 URI 时自动重定向用户代理。如果 URI 不受信任，授权服务器可以告知用户并依靠用户做出正确的决定。
### 混淆代理问题
攻击者可以利用作为第三方 API 中介的 MCP 服务器，导致 [混淆代理漏洞](/specification/2025-06-18/basic/security_best_practices#confused-deputy-problem)。
通过使用窃取的授权码，他们可以在未经用户同意的情况下获取访问令牌。
使用静态客户端 ID 的 MCP 代理服务器 **必须** 在转发到第三方授权服务器之前获得每个动态注册客户端的用户同意（这可能需要额外的同意）。
### 访问令牌权限限制
如果服务器接受为其他资源颁发的令牌，攻击者可以获得未经授权的访问或以其他方式危害 MCP 服务器。
此漏洞有两个关键维度：
1. **受众验证失败。** 当 MCP 服务器不验证令牌是否专门为其意图时（例如，通过受众声明，如 [RFC9068](https://www.rfc-editor.org/rfc/rfc9068.html) 中所述），它可能接受最初为其他服务颁发的令牌。这破坏了基本的 OAuth 安全边界，允许攻击者跨不同服务重用合法令牌，而非预期用途。
2. **令牌传递。** 如果 MCP 服务器不仅接受具有错误受众的令牌，还将这些未修改的令牌转发给下游服务，它可能会导致 ["混淆代理"问题](#confused-deputy-problem)，其中下游 API 可能错误地信任令牌，仿佛它来自 MCP 服务器，或假设令牌已由上游 API 验证。有关更多详细信息，请参阅安全最佳实践指南的 [令牌传递部分](/specification/2025-06-18/basic/security_best_practices#token-passthrough)。
MCP 服务器 **必须** 在处理请求之前验证访问令牌，确保访问令牌是专门为 MCP 服务器颁发的，并采取所有必要步骤确保没有数据返回给未经授权的方。
MCP 服务器 **必须** 遵循 [OAuth 2.1 - 第 5.2 节](https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-13.html#section-5.2) 中的指南来验证入站令牌。
MCP 服务器 **必须** 仅接受专门为其意图的令牌，并 **必须** 拒绝未在受众声明中包含它们或以其他方式验证它们是令牌预期接收者的令牌。有关详细信息，请参阅 [安全最佳实践令牌传递部分](/specification/2025-06-18/basic/security_best_practices#token-passthrough)。
如果 MCP 服务器向上游 API 发出请求，它可能作为它们的 OAuth 客户端。
在上游 API 使用的访问令牌是一个单独的令牌，由上游授权服务器颁发。
MCP 服务器 **不得** 传递其从 MCP 客户端收到的令牌。
MCP 客户端 **必须** 实施并使用 [RFC 8707 - OAuth 2.0 资源指示器](https://www.rfc-editor.org/rfc/rfc8707.html) 中定义的 `resource` 参数
以明确指定请求令牌的目标资源。此要求符合 [RFC 9728 第 7.4 节](https://datatracker.ietf.org/doc/html/rfc9728#section-7.4) 中的建议。这确保访问令牌绑定到其预期资源，并且不能在不同服务之间被滥用。