Skip to main content

​
引言

​
目的和范围

Model Context Protocol 在传输层提供授权能力， 使 MCP 客户端能够代表资源所有者向受限的 MCP 服务器发出请求。本规范定义了基于 HTTP 的传输的授权流程。

​
协议要求

授权对于 MCP 实现是 可选的。当支持时：
  • 使用基于 HTTP 传输的实现 应 符合本规范。
  • 使用 STDIO 传输的实现 不应 遵循本规范，而应从环境中获取凭证。
  • 使用替代传输的实现 必须 遵循其协议既定的安全最佳实践。

​
标准合规性

此授权机制基于以下列出的既定规范，但 实现了其功能的选定子集，以确保安全性和互操作性，同时保持简单性：

​
授权流程

​
概述

  1. MCP 认证实现 必须 为机密和公共客户端实施 OAuth 2.1 并采取适当的安全措施。
  2. MCP 认证实现 应 支持 OAuth 2.0 动态客户端注册协议 (RFC7591)。
  3. MCP 服务器 应 且 MCP 客户端 必须 实现 OAuth 2.0 授权服务器元数据 (RFC8414)。不支持授权服务器元数据的服务器 必须 遵循默认 URI 模式。

​
OAuth 授权类型

OAuth 指定了不同的流程或授权类型，它们是获取访问令牌的不同方式。每种类型针对不同的用例和场景。 MCP 服务器 应 支持最符合目标受众的 OAuth 授权类型。例如：
  1. 授权码：当客户端代表（人类）最终用户行事时有用。
    • 例如，代理调用由 SaaS 系统实现的 MCP 工具。
  2. 客户端凭证：客户端是另一个应用程序（非人类）
    • 例如，代理调用安全的 MCP 工具来检查特定商店的库存。无需模拟最终用户。

​
示例：授权码授权类型

这演示了用于用户认证的授权码授权类型的 OAuth 2.1 流程。 注意：以下示例假设 MCP 服务器也充当授权服务器。但是，授权服务器可能部署为其自己的独立服务。 人类用户通过网页浏览器完成 OAuth 流程，获得一个个人身份识别的访问令牌，并允许客户端代表其行事。 当需要授权且客户端尚未证明时，服务器 必须 响应 HTTP 401 未授权。 客户端在收到 HTTP 401 未授权 后启动 OAuth 2.1 IETF 草案 授权流程。 以下演示了使用 PKCE 的公共客户端的基本 OAuth 2.1。

​
服务器元数据发现

对于服务器能力发现：
  • MCP 客户端 必须 遵循 RFC8414 中定义的 OAuth 2.0 授权服务器元数据协议。
  • MCP 服务器 应 遵循 OAuth 2.0 授权服务器元数据协议。
  • 不支持 OAuth 2.0 授权服务器元数据协议的 MCP 服务器，必须 支持回退 URL。
发现流程如下所示：

​
服务器元数据发现头

MCP 客户端 应 在服务器元数据发现期间包含头 MCP-Protocol-Version: <protocol-version>，以允许 MCP 服务器根据 MCP 协议版本进行响应。 例如：MCP-Protocol-Version: 2024-11-05

​
授权基础 URL

授权基础 URL 必须 通过丢弃任何现有 path 组件从 MCP 服务器 URL 确定。例如： 如果 MCP 服务器 URL 是 https://api.example.com/v1/mcp，则：
  • 授权基础 URL 是 https://api.example.com
  • 元数据端点 必须 位于 https://api.example.com/.well-known/oauth-authorization-server
这确保了授权端点始终位于托管 MCP 服务器的域名的根级别，无论 MCP 服务器 URL 中是否有任何路径组件。

​
无元数据发现服务器的回退方案

对于未实现 OAuth 2.0 授权服务器元数据的服务器，客户端 必须 使用相对于 授权基础 URL 的以下默认端点路径：
端点默认路径描述
授权端点/authorize用于授权请求
令牌端点/token用于令牌交换和刷新
注册端点/register用于动态客户端注册
例如，对于托管在 https://api.example.com/v1/mcp 的 MCP 服务器，默认端点将是：
  • https://api.example.com/authorize
  • https://api.example.com/token
  • https://api.example.com/register
客户端 必须 首先尝试通过元数据文档发现端点，然后再回退到默认路径。使用默认路径时，所有其他协议要求保持不变。

​
动态客户端注册

MCP 客户端和服务器 应 支持 OAuth 2.0 动态客户端注册协议，以允许 MCP 客户端无需用户交互即可获得 OAuth 客户端 ID。这为客户端提供了一种与新服务器自动注册的标准方式，这对 MCP 至关重要，因为：
  • 客户端无法预先知道所有可能的服务器
  • 手动注册会给用户造成不便
  • 它能够无缝连接到新服务器
  • 服务器可以实现自己的注册策略
任何 不 支持动态客户端注册的 MCP 服务器都需要提供替代方式来获取客户端 ID（以及适用的客户端密钥）。对于其中之一的服务器，MCP 客户端将不得不：
  1. 硬编码专门针对该 MCP 服务器的客户端 ID（以及适用的客户端密钥），或
  2. 向用户提供一个 UI，允许他们在自己注册 OAuth 客户端后输入这些详细信息（例如，通过服务器托管的配置界面）。

​
授权流程步骤

完整的授权流程如下进行：

​
决策流程概述

​
访问令牌使用

​
令牌要求

访问令牌处理 必须 符合 OAuth 2.1 第 5 节 对资源请求的要求。具体而言：
  1. MCP 客户端 必须 使用授权请求头字段 第 5.1.1 节：
Authorization: Bearer <access-token>
请注意，授权 必须 包含在从客户端到服务器的每个 HTTP 请求中，即使它们是同一逻辑会话的一部分。
  1. 访问令牌 不得 包含在 URI 查询字符串中
示例请求： 
GET /v1/contexts HTTP/1.1
Host: mcp.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

​
令牌处理

资源服务器 必须 按照 第 5.2 节 中所述验证访问令牌。如果验证失败，服务器 必须 根据 第 5.3 节 错误处理要求进行响应。无效或过期的令牌 必须 收到 HTTP 401 响应。

​
安全考量

必须实施以下安全要求：
  1. 客户端 必须 遵循 OAuth 2.0 最佳实践安全地存储令牌
  2. 服务器 应 强制令牌过期和轮换
  3. 所有授权端点 必须 通过 HTTPS 提供服务
  4. 服务器 必须 验证重定向 URI 以防止开放重定向漏洞
  5. 重定向 URI 必须 是 localhost URL 或 HTTPS URL

​
错误处理

服务器 必须 为授权错误返回适当的 HTTP 状态码：
状态码描述用法
401未授权需要授权或令牌无效
403禁止无效的范围或权限不足
400错误请求授权请求格式错误

​
实现要求

  1. 实现 必须 遵循 OAuth 2.1 安全最佳实践
  2. 所有客户端 必须 使用 PKCE
  3. 应 实施令牌轮换以增强安全性
  4. 令牌生命周期 应 根据安全要求进行限制

​
第三方授权流程

​
概述

MCP 服务器 可以 支持通过第三方授权服务器进行委托授权。在此流程中，MCP 服务器既充当 OAuth 客户端（针对第三方认证服务器），又充当 OAuth 授权服务器（针对 MCP 客户端）。

​
流程描述

第三方授权流程包含以下步骤：
  1. MCP 客户端与 MCP 服务器启动标准 OAuth 流程
  2. MCP 服务器将用户重定向到第三方授权服务器
  3. 用户在第三方服务器授权
  4. 第三方服务器携带授权码重定向回 MCP 服务器
  5. MCP 服务器交换代码获取第三方访问令牌
  6. MCP 服务器生成绑定到第三方会话的自有访问令牌
  7. MCP 服务器完成与 MCP 客户端的原始 OAuth 流程

​
会话绑定要求

实施第三方授权的 MCP 服务器 必须：
  1. 维护第三方令牌与已发行 MCP 令牌之间的安全映射
  2. 在承认 MCP 令牌之前验证第三方令牌状态
  3. 实施适当的令牌生命周期管理
  4. 处理第三方令牌过期和更新

​
安全考量

实施第三方授权时，服务器 必须：
  1. 验证所有重定向 URI
  2. 安全存储第三方凭证
  3. 实施适当的会话超时处理
  4. 考虑令牌链的安全影响
  5. 为第三方认证失败实施适当的错误处理

​
最佳实践

​
本地客户端作为公共 OAuth 2.1 客户端

我们强烈建议本地客户端将 OAuth 2.1 实现为公共客户端：
  1. 在授权请求中使用代码挑战（PKCE）以防止拦截攻击
  2. 实施适合本地系统的安全令牌存储
  3. 遵循令牌刷新最佳实践以维持会话
  4. 正确处理令牌过期和更新

​
授权元数据发现

我们强烈建议所有客户端实现元数据发现。这减少了用户手动提供端点或客户端回退到定义默认值的需求。

​
动态客户端注册

由于客户端事先不知道 MCP 服务器的集合，我们强烈建议实现动态客户端注册。这允许应用程序自动向 MCP 服务器注册，并消除了用户手动获取客户端 ID 的需求。