Skip to content

2.7 MCP 授权机制:Authorization

MCP 通过授权机制,为受保护的 MCP 服务器向客户端暴露数据提供了一种标准方式。授权的本质是 MCP 客户端代表资源所有者向受限的 MCP 服务器发起请求。

按照 MCP 的要求,基于 stdio 传输实现的 MCP 服务器,应该从环境变量读取授权凭证。而基于 HTTP 传输实现的 MCP 服务器,应该基于 OAuth 2.1 实现授权机制。

2.7.1 介绍 OAuth 2.1

在介绍 OAuth 2.1 之前,我们先来了解一下 OAuth 2.0 。

OAuth 2.0 是一个开放标准的授权框架,允许第三方应用在不获取用户密码的情况下访问用户的受保护资源。OAuth 2.0 为现代互联网应用提供了标准化的授权解决方案,平衡了安全性和易用性,是目前最主流的授权框架,广泛应用于社交登录(谷歌登录、Github 登录、微信登录等)、API 访问控制、第三方应用集成。

OAuth 2.1 是 OAuth 2.0 授权框架的最新版本,旨在简化流程和增强安全性。

OAuth 2.1 的核心概念和角色如下:

  1. 资源所有者(Resource Owner):通常是用户
  2. 客户端(Client):请求访问的应用程序
  3. 资源服务器(Resource Server):存储受保护资源的服务器
  4. 授权服务器(Authorization Server):验证身份并颁发访问令牌

OAuth 2.1 支持的令牌类型如下:

  1. 访问令牌(Access Token):用于访问受保护资源
  2. 刷新令牌(Refresh Token):用于获取新的访问令牌
  3. 授权码(Authorization Code):临时的授权凭证

OAuth 2.1 中最主要和推荐的流程是授权码流程 + PKCE(Proof Key for Code Exchange,代码交换证明密钥),其步骤如下:

  1. 客户端生成 code_verifier 和 code_challenge
  2. 重定向用户到授权服务器
  3. 用户授权后获得授权码
  4. 客户端使用授权码和 code_verifier 交换访问令牌

2.7.2 MCP 授权基本流程

MCP 授权的基本流程如图所示:

流程说明:

  1. 初始请求阶段:客户端向 MCP 服务器发送请求,收到 401 未授权响应
  2. PKCE 准备:客户端生成 code_verifier 和 code_challenge
  3. 用户授权:通过浏览器进行用户授权流程
  4. 令牌交换:使用授权码换取访问令牌
  5. 正常通信:使用访问令牌进行标准 MCP 消息交换

2.7.3 授权服务器元数据发现

在上一步的 MCP 授权基本流程中,默认把 MCP 服务器也看做是授权服务器,并使用默认的服务器端点完成了授权流程。

但在实际使用中,授权服务器可能独立于 MCP 服务器存在,授权端点也可能不同。因此,MCP 客户端需要实现 OAuth 2.0 规定的授权服务器元数据发现流程,并根据元数据定义的授权端点完成授权流程。

授权服务器元数据发现流程如图所示:

流程说明:

  1. 客户端向 MCP 服务器发送请求,获取授权服务器元数据
  2. 如果 MCP 服务器返回 200 响应,表示 MCP 服务器有实现授权服务器元数据发现,客户端根据元数据中的授权端点继续后面的授权流程
  3. 如果 MCP 服务器返回 404 响应,表示 MCP 服务器没有实现授权服务器元数据发现,客户端使用默认的授权端点完成授权流程

对于没有实现授权服务器元数据发现的 MCP 服务器,客户端必须使用以下相对于授权基础 URL 的默认端点路径:

端点默认路径描述
授权端点/authorize用于授权请求
令牌端点/token用于令牌交换和刷新
注册端点/register用于动态客户端注册

2.7.4 动态客户端注册

在上一步的授权服务器元数据发现流程中,客户端从授权服务器元数据中获取了授权端点,比如是:/authorize。

按照 2.7.2 介绍的基本授权流程,客户端需要重定向用户到授权端点,并携带客户端参数。在常见 Web 应用 OAuth 授权场景,客户端参数需要提前在服务器注册获得(比如在 Github 创建应用后得到 client_id 和 client_secret)。

然而,MCP 服务器是海量的,如果客户端需要为每个 MCP 服务器提前申请授权参数,成本将会非常高。因此,MCP 客户端和 MCP 服务器需要支持 OAuth 2.0 规定的动态客户端注册流程。

流程说明:

  1. 客户端首先通过元数据发现获取注册端点,比如是: /register
  2. 客户端向注册端点发送请求,携带客户端信息(名称、版本、回调地址等)
  3. 服务器注册客户端,返回授权参数(client_id 和 client_secret 等)

加上授权服务器元数据发现和动态客户端注册流程的 MCP 授权流程如图所示:

2.7.5 访问令牌使用

在通过授权流程得到访问令牌后,客户端在访问 MCP 服务器受保护资源时,需要携带访问令牌。发送的 HTTP 请求示例如下:

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

MCP 服务器需要验证客户端访问令牌的合法性,并根据访问令牌的权限决定是否返回受保护资源。如果客户端请求的令牌无效或已过期,服务器必须返回 401 未授权响应。

2.7.6 第三方授权流程

MCP 服务器可能通过第三方授权服务器支持委托授权。在这个流程中,MCP 服务器同时充当 OAuth 客户端(对第三方授权服务器)和 OAuth 授权服务器(对 MCP 客户端)。

第三方授权流程如图所示:

流程说明:

  1. MCP 客户端与 MCP 服务器启动标准 OAuth 流程
  2. MCP 服务器将用户重定向到第三方授权服务器
  3. 用户通过第三方服务器进行授权
  4. 第三方服务器携带授权码重定向回 MCP 服务器
  5. MCP 服务器用代码交换第三方访问令牌
  6. MCP 服务器生成绑定到第三方会话的自己的访问令牌
  7. MCP 服务器与 MCP 客户端完成原始 OAuth 流程