授权 - 模型上下文协议

引言

目的与范围

模型上下文协议在传输层面提供授权能力，使 MCP 客户端能够代表资源所有者向受限的 MCP 服务器发起请求。本规范定义用于基于 HTTP 的传输的授权流程。

协议要求

授权对 MCP 实现而言是**可选（OPTIONAL）**的。当被支持时：

使用基于 HTTP 的传输的实现**应当（SHOULD）**遵循本规范。
使用 STDIO 传输的实现**不应（SHOULD NOT）**遵循本规范，而应改为从环境中检索凭据。
使用替代传输的实现**必须（MUST）**遵循其协议既定的安全最佳实践。

标准合规性

此授权机制基于下面列出的既定规范，但实现了它们特性的一个选定子集，以在保持简单的同时确保安全和互操作性：

OAuth 2.1 IETF DRAFT（draft-ietf-oauth-v2-1-13）
OAuth 2.0 Bearer Token Usage（RFC6750）
OAuth 2.0 Authorization Server Metadata（RFC8414）
OAuth 2.0 Dynamic Client Registration Protocol（RFC7591）
Resource Indicators for OAuth 2.0（RFC8707）
OAuth 2.0 Protected Resource Metadata（RFC9728）
OAuth 2.0 Authorization Server Issuer Identification（RFC9207）
OAuth Client ID Metadata Documents（draft-ietf-oauth-client-id-metadata-document-00）
OpenID Connect Discovery 1.0
OpenID Connect Dynamic Client Registration 1.0（OpenID Connect Registration）

角色

一个受保护的 _MCP 服务器_充当一个 OAuth 2.1 资源服务器，能够使用访问令牌接受和响应受保护的资源请求。一个 _MCP 客户端_充当一个 OAuth 2.1 客户端，代表资源所有者发起受保护的资源请求。 _授权服务器_负责（如有必要）与用户交互并签发供在 MCP 服务器使用的访问令牌。授权服务器的实现细节超出本规范的范围。它可以与资源服务器一起托管，也可以是一个单独的实体。授权服务器发现指定 MCP 服务器如何向客户端指示其对应授权服务器的位置。

概述

授权服务器**必须（MUST）**为机密客户端和公共客户端实现带适当安全措施的 OAuth 2.1。
授权服务器和 MCP 客户端**应当（SHOULD）**支持 OAuth Client ID Metadata Documents（draft-ietf-oauth-client-id-metadata-document-00）。
授权服务器和 MCP 客户端**可以（MAY）**支持 OAuth 2.0 动态客户端注册协议（RFC7591）。请注意，动态客户端注册已弃用，为与不支持客户端 ID 元数据文档的授权服务器向后兼容而保留。
MCP 服务器**必须（MUST）实现 OAuth 2.0 Protected Resource Metadata（RFC9728）。MCP 客户端必须（MUST）**使用 OAuth 2.0 Protected Resource Metadata 进行授权服务器发现。
MCP 授权服务器**必须（MUST）**提供以下发现机制中的至少一个：
- OAuth 2.0 Authorization Server Metadata（RFC8414）
- OpenID Connect Discovery 1.0
MCP 客户端**必须（MUST）**支持两种发现机制，以获取与授权服务器交互所需的信息。

授权服务器发现

MCP 服务器通过 OAuth 2.0 Protected Resource Metadata 公布其关联的授权服务器，而 MCP 客户端通过授权服务器元数据发现确定授权服务器端点和所支持的能力。实现**必须（MUST）**遵循授权服务器发现中定义的规范性发现要求。

客户端注册

在发起授权流程之前，MCP 客户端**必须（MUST）**通过三种注册机制之一获取一个 client ID：客户端 ID 元数据文档、预注册，或动态客户端注册，遵循客户端注册中定义的要求和选择优先级。

Scope 选择策略

MCP 服务器**应当（SHOULD）**在 WWW-Authenticate header 中包含一个 scope 参数（如 RFC 6750 第 3 节所定义），以指示访问该资源所需的 scope。这为客户端提供关于在授权期间请求适当 scope 的即时指导，遵循最小权限原则并防止客户端请求过多的权限。 WWW-Authenticate 质询中包含的 scope **可以（MAY）与 scopes_supported 匹配、是它的子集或超集，或是既非严格子集也非超集的另一个集合。客户端不得（MUST NOT）假定被质询的 scope 集与 scopes_supported 之间有任何特定的集合关系。客户端必须（MUST）将质询中提供的 scope 视为对当前操作具有权威性。这些 scope 是满足当前请求所必需的。在重新授权时，客户端应当（SHOULD）将这些 scope 与任何先前授予的 scope 一起包含，以避免丢失其他操作所需的权限（参见升级授权流程）。服务器应当（SHOULD）**力求在如何构造 scope 集方面保持一致，但它们不要求通过 scopes_supported 呈现每个动态签发的 scope。带 scope 指导的 401 响应示例：

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

在实现授权流程时，MCP 客户端**应当（SHOULD）遵循最小权限原则，只请求其预期操作所必需的 scope。在初始授权握手期间，MCP 客户端应当（SHOULD）**遵循以下 scope 选择的优先级顺序：

使用来自 401 响应中初始 WWW-Authenticate header 的 scope 参数（如果提供）
如果 scope 不可用，使用受保护资源元数据文档中 scopes_supported 定义的所有 scope；若 scopes_supported 未定义，则省略 scope 参数。

scopes_supported 字段旨在表示基本功能所必需的最小 scope 集（参见 Scope 最小化），额外的 scope 通过 Scope 质询处理一节中描述的升级授权流程步骤增量地请求。

授权流程步骤

流程中所示的注册步骤使用客户端注册中定义的机制之一。完整的授权流程如下进行：

授权响应校验

在重定向用户代理之前，客户端**必须（MUST）**记录所选授权服务器已校验元数据文档中的 issuer 值（参见授权服务器元数据发现），并将它与用于存储 PKCE code verifier（以及 state 值，如果使用）的同一个每请求记录关联起来。本节中的校验依赖于该记录值是真实的；如果预期的 issuer 从一个未校验的来源获得，它不提供任何保护。 MCP 授权服务器**应当（SHOULD）在授权响应（包括错误响应）中包含 iss 参数，如 RFC9207 第 2 节所定义。包含 iss 参数的授权服务器必须（MUST）**通过在其元数据中将 authorization_response_iss_parameter_supported 设为 true 来公布这一点（RFC9207 第 2.3 节）。在收到授权响应时，MCP 客户端在将授权码传输到任何令牌端点之前**必须（MUST）**应用 RFC9207 第 2.4 节中的校验：

`authorization_response_iss_parameter_supported`	响应中的 `iss`	客户端行为
`true`	存在	使用简单字符串比较（RFC3986 第 6.2.1 节）与记录的 issuer 比较
`true`	缺失	拒绝该响应
`false` 或缺失	存在	使用简单字符串比较（RFC3986 第 6.2.1 节）与记录的 issuer 比较
`false` 或缺失	缺失	继续

第三行应用 RFC9207 第 2.4 节中的本地策略条款：本规范无论元数据公布情况如何，都将存在的 iss 与记录的 issuer 比较，以适应在更新其元数据之前就发出 iss 的授权服务器。预期本规范的未来修订版会将授权服务器对 iss 的包含从应当（SHOULD）升级为必须（MUST）。鼓励实现者现在就发出并校验 iss 以缓解该过渡；客户端在 iss 缺失时的拒绝行为将继续关联到 authorization_response_iss_parameter_supported，直到该修订版定义了升级路径。在根据 RFC 9207 第 2.4 节从 application/x-www-form-urlencoded 响应中解码 iss 值之后，客户端在比较之前**不得（MUST NOT）**应用 scheme 或 host 大小写折叠、默认端口省略、尾部斜杠，或百分号编码规范化（RFC 3986 第 6.2.2-6.2.3 节）。此校验同样适用于错误响应——在不匹配时，客户端**不得（MUST NOT）**对 error、error_description 或 error_uri 采取行动或显示它们。

Resource 参数实现

MCP 客户端**必须（MUST）**实现 RFC 8707 中定义的 Resource Indicators for OAuth 2.0，以显式指定正在为其请求令牌的目标资源。resource 参数：

**必须（MUST）**同时包含在授权请求和令牌请求中。
**必须（MUST）**标识客户端打算将令牌用于的 MCP 服务器。
**必须（MUST）**使用 RFC 8707 第 2 节中定义的 MCP 服务器规范 URI。

规范服务器 URI

就本规范而言，MCP 服务器的规范 URI 被定义为 RFC 8707 第 2 节中指定的资源标识符，并与 RFC 9728 中的 resource 参数对齐。 MCP 客户端**应当（SHOULD）为它们打算访问的 MCP 服务器提供它们所能提供的最具体的 URI，遵循 RFC 8707 中的指导。虽然规范形式使用小写的 scheme 和 host 组成部分，但实现应当（SHOULD）**为健壮性和互操作性接受大写的 scheme 和 host 组成部分。有效规范 URI 的示例：

https://mcp.example.com/mcp
https://mcp.example.com
https://mcp.example.com:8443
https://mcp.example.com/server/mcp（当需要 path 组成部分来标识单个 MCP 服务器时）

无效规范 URI 的示例：

mcp.example.com（缺少 scheme）
https://mcp.example.com#fragment（包含 fragment）

注意： 虽然根据 RFC 3986，https://mcp.example.com/（带尾部斜杠）和 https://mcp.example.com（不带尾部斜杠）在技术上都是有效的绝对 URI，但除非尾部斜杠对特定资源在语义上是重要的，否则实现**应当（SHOULD）**一致地使用不带尾部斜杠的形式以获得更好的互操作性。

例如，如果访问一个位于 https://mcp.example.com 的 MCP 服务器，授权请求将包含：

&resource=https%3A%2F%2Fmcp.example.com

无论授权服务器是否支持此参数，MCP 客户端都**必须（MUST）**发送它。

访问令牌的使用

令牌要求

在向 MCP 服务器发起请求时的访问令牌处理**必须（MUST）**符合 OAuth 2.1 第 5 节 “Resource Requests”中定义的要求。具体而言：

MCP 客户端**必须（MUST）**使用 OAuth 2.1 第 5.1.1 节中定义的 Authorization 请求 header 字段：

Authorization: Bearer <access-token>

请注意，authorization **必须（MUST）**包含在每个从客户端到服务器的 HTTP 请求中。

访问令牌**不得（MUST NOT）**包含在 URI 查询字符串中

请求示例：

GET /mcp HTTP/1.1
Host: mcp.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

令牌处理

MCP 服务器以其作为 OAuth 2.1 资源服务器的角色，**必须（MUST）如 OAuth 2.1 第 5.2 节所述校验访问令牌。MCP 服务器必须（MUST）根据 RFC 8707 第 2 节校验访问令牌是专门为它们作为预期 audience 而签发的。如果校验失败，服务器必须（MUST）根据 OAuth 2.1 第 5.3 节的错误处理要求响应。无效或过期的令牌必须（MUST）**收到一个 HTTP 401 响应。 MCP 客户端**不得（MUST NOT）**向 MCP 服务器发送除 MCP 服务器的授权服务器所签发之外的令牌。 MCP 服务器**必须（MUST）**只接受对其自身资源有效的令牌。 MCP 服务器**不得（MUST NOT）**接受或中转任何其他令牌。

刷新令牌

本节为 MCP 客户端和 MCP 服务器在处理或签发 OAuth 和 OpenID Connect 的刷新令牌时提供指导。 MCP 客户端如果想要刷新令牌：

**必须（MUST）**如 OAuth 2.1 第 4.3 节所指定，在传输和存储中对刷新令牌保密
**应当（SHOULD）**在其 grant_types 客户端元数据中包含 refresh_token
当授权服务器元数据在 scopes_supported 中包含 offline_access 时，**可以（MAY）**将 offline_access 添加到授权和令牌请求的 scope 参数中
**不得（MUST NOT）**假定会签发刷新令牌；授权服务器保留自由裁量权

MCP 服务器（受保护资源）**不应（SHOULD NOT）**在 WWW-Authenticate scope 或受保护资源元数据 scopes_supported 中包含 offline_access，因为刷新令牌不是一项资源要求。

错误处理

服务器**必须（MUST）**为授权错误返回适当的 HTTP 状态码：

状态码	描述	用途
401	Unauthorized	需要授权或令牌无效
403	Forbidden	无效的 scope 或权限不足
400	Bad Request	格式错误的授权请求

Scope 质询处理

本节涵盖在运行时操作期间处理 scope 不足错误的情况——当客户端已经有一个令牌但需要额外权限时。这遵循 OAuth 2.1 第 5 节中定义的错误处理模式，并利用 RFC 9728（OAuth 2.0 Protected Resource Metadata）中的元数据字段。

运行时 scope 不足错误

当客户端在运行时操作期间使用一个 scope 不足的访问令牌发起请求时，服务器**应当（SHOULD）**以下列内容响应：

HTTP 403 Forbidden 状态码（根据 RFC 6750 第 3.1 节）
带 Bearer scheme 和额外参数的 WWW-Authenticate header：
- error="insufficient_scope" —— 指示授权失败的具体类型
- scope="required_scope1 required_scope2" —— 指定该操作所需的最小 scope
- resource_metadata —— 受保护资源元数据文档的 URI（为了与 401 响应保持一致）
- error_description（可选）—— 错误的人类可读描述

服务器 scope 管理：在以 scope 不足错误响应时，服务器**应当（SHOULD）**在 scope 参数中包含满足当前操作所需的 scope，与 RFC 6750 第 3.1 节一致。scope 属性描述访问所请求资源所必需的 scope——服务器不要求包含客户端先前授予的 scope。无论服务器采用何种 scope 包含策略，服务器**应当（SHOULD）**在单个质询中包含当前操作所需的所有 scope。增量地质询（返回一个缺失的 scope，然后在后续重试中返回另一个）迫使单个操作进行多次授权往返，并降低用户体验。所需的 scope 可以基于具体的请求参数和上下文动态确定，但一旦确定，它们应被一起发出。服务器**应当（SHOULD）**在其 scope 包含策略中保持一致，以为客户端提供可预测的行为。服务器在确定响应中包含哪些 scope 时**应当（SHOULD）**考虑用户体验影响，因为配置错误的 scope 可能需要频繁的用户交互。跨操作的 scope 累积是客户端侧的责任。scope 并集要求参见升级授权流程。 scope 不足响应示例：

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                         scope="files:write",
                         resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         error_description="File write permission required for this operation"

升级授权流程

客户端会在初始授权期间或运行时收到 scope 相关的错误（insufficient_scope）。客户端**应当（SHOULD）通过一个升级授权流程请求一个带有增加的 scope 集的新访问令牌来响应这些错误，或以其他适当的方式处理这些错误。代表用户行事的客户端应当（SHOULD）**尝试升级授权流程。代表自己行事的客户端（client_credentials 客户端）**可以（MAY）**尝试升级授权流程或立即中止请求。流程如下：

从授权服务器响应或 WWW-Authenticate header 解析错误信息
确定所需的 scope，方法是计算客户端先前请求的 scope 集与当前质询的 scope 的并集。这确保当服务器根据 RFC 6750 第 3.1 节发出按操作的 scope 质询时，先前授予的权限被保留。客户端**可以（MAY）**还参考 Scope 选择策略以获得初始 scope 选择的指导。
用确定的 scope 集发起（重新）授权
用新授权重试原始请求不超过几次，并将此视为永久性授权失败

客户端**应当（SHOULD）实现重试限制，并应当（SHOULD）**跟踪 scope 升级尝试，以避免对同一资源和操作组合的重复失败。服务器在决定一个令牌对某个操作是否足够时，**必须（MUST）**考虑 scope 层级，其中一个更宽泛的 scope 隐含更窄的 scope。

安全考量

本规范的实现**必须（MUST）**遵循安全考量中的规范性安全要求，涵盖令牌 audience 绑定和校验、令牌盗窃、通信安全、授权码保护、混淆（mix-up）和混淆代理攻击、开放重定向，以及客户端 ID 元数据文档安全。

MCP 授权扩展

有若干对核心协议的授权扩展定义了额外的授权机制。这些扩展是：

可选 —— 实现可以选择采用这些扩展
附加 —— 扩展不修改或破坏核心协议功能；它们在保留核心协议行为的同时添加新能力
可组合 —— 扩展是模块化的，并被设计为可以无冲突地协同工作，允许实现同时采用多个扩展
独立版本化 —— 扩展遵循核心 MCP 版本管理周期，但可以根据需要采用独立的版本管理

受支持扩展的列表可在 MCP Authorization Extensions 仓库中找到。

基础协议

客户端特性

服务器特性

授权

引言

目的与范围

协议要求

标准合规性

角色

概述

授权服务器发现

客户端注册

Scope 选择策略

授权流程步骤

授权响应校验

Resource 参数实现

规范服务器 URI

访问令牌的使用

令牌要求

令牌处理

刷新令牌

错误处理

Scope 质询处理

运行时 scope 不足错误

升级授权流程

安全考量

MCP 授权扩展

​引言

​目的与范围

​协议要求

​标准合规性

​角色

​概述

​授权服务器发现

​客户端注册

​Scope 选择策略

​授权流程步骤

​授权响应校验

​Resource 参数实现

​规范服务器 URI

​访问令牌的使用

​令牌要求

​令牌处理

​刷新令牌

​错误处理

​Scope 质询处理

​运行时 scope 不足错误

​升级授权流程

​安全考量

​MCP 授权扩展

引言

目的与范围

协议要求

标准合规性

角色

概述

授权服务器发现

客户端注册

Scope 选择策略

授权流程步骤

授权响应校验

Resource 参数实现

规范服务器 URI

访问令牌的使用

令牌要求

令牌处理

刷新令牌

错误处理

Scope 质询处理

运行时 scope 不足错误

升级授权流程

安全考量

MCP 授权扩展