授权

简介

目的与范围

Model Context Protocol 在传输层提供授权能力，使 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 客户端 ID 元数据文档 (draft-ietf-oauth-client-id-metadata-document-00)。
授权服务器和 MCP 客户端 MAY（可以）支持 OAuth 2.0 动态客户端注册协议 (RFC7591)。请注意，动态客户端注册已弃用，保留它是为了向后兼容不支持客户端 ID 元数据文档的授权服务器。
MCP 服务端 MUST（必须）实现 OAuth 2.0 受保护资源元数据 (RFC9728)。 MCP 客户端 MUST（必须）使用 OAuth 2.0 受保护资源元数据进行授权服务器发现。
MCP 授权服务器 MUST（必须）提供以下发现机制中的至少一种：
- OAuth 2.0 授权服务器元数据 (RFC8414)
- OpenID Connect Discovery 1.0
MCP 客户端 MUST（必须）同时支持这两种发现机制，以获取与授权服务器交互所需的信息。

授权服务器发现

MCP 服务端通过 OAuth 2.0 受保护资源元数据公布其关联的授权服务器，MCP 客户端则通过授权服务器元数据发现来确定授权服务器端点及支持的能力。实现 MUST（必须）遵循授权服务器发现中定义的规范性发现要求。

客户端注册

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

范围选择策略

MCP 服务端 SHOULD（应当）按照 RFC 6750 第 3 节的定义，在 WWW-Authenticate 头中包含 scope 参数，以指示访问该资源所需的范围。这为客户端在授权期间请求适当范围提供了即时指引，遵循最小权限原则并防止客户端请求过多权限。 WWW-Authenticate 质询中包含的范围 MAY（可以）与 scopes_supported 匹配，可以是其子集或超集，也可以是既非严格子集也非超集的另一种集合。客户端 MUST NOT（不得）假定质询范围集合与 scopes_supported 之间存在任何特定的集合关系。客户端 MUST（必须）将质询中提供的范围视为当前操作的权威依据。这些范围是满足当前请求所必需的。在重新授权时，客户端 SHOULD（应当）将这些范围与先前授予的任何范围一并包含，以避免丢失其他操作所需的权限（参见升级授权流程）。服务端 SHOULD（应当）力求在构造范围集合的方式上保持一致，但并不要求通过 scopes_supported 暴露每一个动态签发的范围。

带范围指引的 401 响应示例：

http

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

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

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

scopes_supported 字段旨在表示基本功能所需的最小范围集合（参见范围最小化），其他范围则通过范围质询处理一节中描述的升级授权流程步骤逐步请求。

授权流程步骤

流程中所示的注册步骤使用客户端注册中定义的机制之一。

完整的授权流程如下：

sequenceDiagram
    participant B as User-Agent (Browser)
    participant C as Client
    participant M as MCP Server (Resource Server)
    participant A as Authorization Server

    C->>M: MCP request without token
    M->>C: HTTP 401 Unauthorized with WWW-Authenticate header
    Note over C: Extract resource_metadata URL from WWW-Authenticate

    C->>M: Request Protected Resource Metadata
    M->>C: Return metadata

    Note over C: Parse metadata and extract authorization server(s)<br/>Client determines AS to use

    C->>A: GET Authorization server metadata endpoint
    Note over C,A: Try OAuth 2.0 and OpenID Connect<br/>discovery endpoints in priority order
    A-->>C: Authorization server metadata

    alt Client ID Metadata Documents
        Note over C: Client uses HTTPS URL as client_id
        Note over A: Server detects URL-formatted client_id
        A->>C: Fetch metadata from client_id URL
        C-->>A: JSON metadata document
        Note over A: Validate metadata and redirect_uris
    else Dynamic client registration
        C->>A: POST /register
        A->>C: Client Credentials
    else Pre-registered client
        Note over C: Use existing client_id
    end

    Note over C: Generate PKCE parameters<br/>Include resource parameter<br/>Apply scope selection strategy<br/>Record expected issuer
    C->>B: Open browser with authorization URL + code_challenge + resource
    B->>A: Authorization request with resource parameter
    Note over A: User authorizes
    A->>B: Redirect to callback with authorization code + iss
    B->>C: Authorization code callback
    Note over C: Validate iss against recorded issuer (RFC 9207)
    C->>A: Token request + code_verifier + resource
    A->>C: Access token (+ refresh token)
    C->>M: MCP request with access token
    M-->>C: MCP response
    Note over C,M: MCP communication continues with valid token

授权响应验证

在重定向用户代理之前，客户端 MUST（必须）从所选授权服务器经过验证的元数据文档中记录 issuer 值（参见授权服务器元数据发现），并将其与用于存储 PKCE code verifier（以及 state 值，如果使用）的同一逐请求记录相关联。本节中的验证依赖于所记录的值是真实的；如果预期签发者来自未经验证的来源，则此验证不提供任何保护。

MCP 授权服务器 SHOULD（应当）按照 RFC9207 第 2 节的定义，在授权响应（包括错误响应）中包含 iss 参数。包含 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 节][1]）
`true`	缺失	拒绝该响应
`false` 或缺失	存在	使用简单字符串比较与记录的签发者进行比较（[RFC3986 第 6.2.1 节][1]）
`false` 或缺失	缺失	继续处理
[1]: https://datatracker.ietf.org/doc/html/rfc3986#section-6.2.1

第三行应用了 RFC9207 第 2.4 节中的本地策略条款：本规范无论元数据是否声明，都会将存在的 iss 与记录的签发者进行比较，以兼容在更新元数据之前就发出 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 采取行动或进行显示。

资源参数实现

MCP 客户端 MUST（必须）实现 RFC 8707 中定义的 OAuth 2.0 资源指示符，以明确指定请求令牌所针对的目标资源。resource 参数：

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

规范服务器 URI

就本规范而言，MCP 服务端的规范 URI 定义为 RFC 8707 第 2 节中指定的资源标识符，并与 RFC 9728 中的 resource 参数保持一致。

MCP 客户端 SHOULD（应当）遵循 RFC 8707 中的指引，为其打算访问的 MCP 服务端提供尽可能具体的 URI。虽然规范形式使用小写的 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（当需要路径组件来标识单个 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 请求头字段：

Authorization: Bearer <access-token>

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

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

请求示例：

http

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 节，验证访问令牌是专门以其为预期受众签发的。如果验证失败，服务端 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
MAY（可以）在授权服务器元数据的 scopes_supported 中包含 offline_access 时，将其添加到授权请求和令牌请求的 scope 参数中
MUST NOT（不得）假定会签发刷新令牌；授权服务器保留自行决定权 MCP 服务端（受保护资源）SHOULD NOT（不应）在 WWW-Authenticate scope 或受保护资源元数据 scopes_supported 中包含 offline_access，因为刷新令牌不是资源需求。

错误处理

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

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

范围质询处理

本节涵盖在运行时操作期间，当客户端已持有令牌但需要额外权限时处理范围不足错误的情况。这遵循 OAuth 2.1 第 5 节中定义的错误处理模式，并利用 RFC 9728（OAuth 2.0 受保护资源元数据）中的元数据字段。

运行时范围不足错误

当客户端在运行时操作期间使用范围不足的访问令牌发起请求时，服务端 SHOULD（应当）响应：

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

服务端范围管理：在响应范围不足错误时，服务端 SHOULD（应当）在 scope 参数中包含满足当前操作所需的范围，与 RFC 6750 第 3.1 节保持一致。 scope 属性描述访问所请求资源所需的范围——服务端无需包含客户端先前授予的范围。

无论服务端采用何种范围包含策略，服务端 SHOULD（应当）在单次质询中包含当前操作所需的所有范围。增量式质询（先返回一个缺失范围，再在后续重试时返回另一个）会迫使单个操作进行多次授权往返，从而降低用户体验。所需范围可以根据具体请求参数和上下文动态确定，但一旦确定，就应一并发出。

服务端 SHOULD（应当）在其范围包含策略上保持一致，以便为客户端提供可预测的行为。

服务端 SHOULD（应当）在确定响应中包含哪些范围时考虑用户体验影响，因为范围配置错误可能导致频繁的用户交互。

跨操作的范围累积是客户端的责任。有关范围并集要求，请参见升级授权流程。

范围不足响应示例：

http

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"

升级授权流程

客户端将在初始授权期间或运行时收到与范围相关的错误（insufficient_scope）。客户端 SHOULD（应当）通过升级授权流程请求具有更大范围集合的新访问令牌来响应这些错误，或以其他适当方式处理这些错误。代表用户行事的客户端 SHOULD（应当）尝试升级授权流程。代表自身行事的客户端（client_credentials 客户端） MAY（可以）尝试升级授权流程或立即中止请求。

流程如下：

解析错误信息，来自授权服务器响应或 WWW-Authenticate 头
确定所需范围，通过计算客户端先前请求的范围集合与当前质询中的范围的并集。这确保在服务端按照 RFC 6750 第 3.1 节发出逐操作范围质询时，先前授予的权限得以保留。客户端 MAY（可以）还参考范围选择策略获取初始范围选择指引。
发起（重新）授权，使用确定的范围集合
重试原始请求，使用新的授权，重试次数不超过几次，并将其视为永久性授权失败

客户端 SHOULD（应当）实现重试限制，并 SHOULD（应当）跟踪范围升级尝试，以避免对同一资源和操作组合反复失败。

服务端 MUST（必须）在判断令牌对某操作是否足够时，考虑范围层级关系，即较宽的范围蕴含较窄的范围。

安全考虑

本规范的实现 MUST（必须）遵循安全考虑中的规范性安全要求，涵盖令牌受众绑定与验证、令牌窃取、通信安全、授权码保护、混淆与混淆代理攻击、开放重定向以及客户端 ID 元数据文档安全。

MCP 授权扩展

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

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

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

授权

简介

目的与范围

协议要求

标准符合性

角色

概述

授权服务器发现

客户端注册

范围选择策略

授权流程步骤

授权响应验证

资源参数实现

规范服务器 URI

访问令牌使用

令牌要求

令牌处理

刷新令牌

错误处理

范围质询处理

运行时范围不足错误

升级授权流程

安全考虑

MCP 授权扩展

友情链接