MCP Server 之旅第 5 站：服务鉴权体系解密

作者：梅茜

背景

在系列文章第4篇 MCP Server On FC 之旅4: 长连接闲置计费最高降低87%成本的技术内幕，我们解构了FC在MCP场景下通过闲置计费能力为用户降本的技术内幕和使用方式。本文将从Auth的角度，介绍MCP协议对Auth的支持以及函数计算为适配MCP协议Auth目前提供的能力和之后会开放的能力。

MCP授权机制

MCP在最开始的2024-11-05版本中并没有支持授权，在2025-03-26中，MCP协议支持了基于OAuth2.1的授权机制，在最新的MCP Draft中，社区对基于OAuth 2.1的授权协议内容进行了调整，三个协议版本的授权协议基于的OAuth标准见下表。本节会先简单介绍MCP协议所使用到的几个OAuth协议/子协议，然后分别介绍MCP 2025-03-26版本和最新Draft的授权过程。

MCP版本	是否支持授权	基于的授权协议
2024-11-05	否	-
2025-03-26	是	OAuth 2.1 IETF草案<br/>OAuth 2.0 授权服务器元数据 (RFC8414)<br/>OAuth 2.0 动态客户端注册协议 (RFC7591)
最新Draft	是	OAuth 2.1 IETF 草案<br/>OAuth 2.0 授权服务器元数据 (RFC8414)<br/>OAuth 2.0 动态客户端注册协议 (RFC7591)<br/>OAuth 2.0 受保护资源元数据 (RFC9728)

MCP Auth涉及的相关OAuth协议介绍

如果您对如下的协议已经有所了解，可以直接查看后续的 MCP 协议鉴权流程章节。

OAuth 2.1 IETF草案（draft-ietf-oauth-v2-1-12）

OAuth协议在不暴露用户的用户名和密码的情况下，通过引入访问令牌，以安全、可控的方式允许某个应用访问用户的数据。

在OAuth 2.1授权机制下，OAuth定义了四种角色：

资源所有者：能够授予对受保护资源访问权限的实体。当资源所有者是个人时，被称为最终用户。缩写为“RO”。

资源服务器：托管受保护资源的服务器，能够使用访问令牌接受和响应受保护资源请求。资源服务器通常可以通过 API 访问。缩写为“RS”。

客户端：代表资源所有者并获得其授权的应用程序，用于发起受保护资源请求。

授权服务器：服务器在成功验证资源所有者身份并获得授权后向客户端发放访问令牌。缩写为“AS”。

其大致授权流程如下：

1、客户端向资源所有者请求授权。授权请求可以直接向资源所有者发起，或者通过授权服务器作为中介间接发起。

2、客户端接收授权许可——一种代表资源所有者授权的凭证，使用授权许可类型或扩展授权许可类型来表示。授权许可类型取决于客户端请求授权的方法以及授权服务器支持的类型。

3、客户端通过向授权服务器进行身份验证并提交授权许可来请求访问令牌。

4、授权服务器对客户端进行身份验证并验证授权许可，如果有效，则发放访问令牌。

5、客户端从资源服务器请求受保护的资源，并通过出示访问令牌进行身份验证。

6、资源服务器验证访问令牌，如果有效，则处理请求。

OAuth 2.0 Authorization Server Metadata(RFC8414)

Authorization Server Metadata协议，即ASM协议，解决OAuth 2.0客户端如何和OAuth 2.0的授权服务器交互的问题，包括：授权地址、获取token地址、支持哪些授权方式等。如果没有ASM协议，虽然可以约定授权服务器获取Token的地址、授权地址等信息，但是授权服务器支持的授权方式、支持的授权码类型却因为授权服务器实现的不同，会有所区别，无法静态配置。

其工作流程如下：

1、客户端通过GET请求访问授权服务器的/.well-known/oauth-authorization-server路径；

2、授权服务器返回授权服务器配置的声明，包括所有必要的端点和公钥位置信息。响应体示例（实际的ASM协议响应可包含更多的内容，见RFC8414）：

HTTP/1.1 200 OK
Content-Type: application/json

{
  "issuer": "https://auth.example.com",
  "authorization_endpoint": "https://auth.example.com/oauth/authorize",
  "token_endpoint": "https://auth.example.com/oauth/token",
  "response_types_supported": ["code", "token"],
  "grant_types_supported": ["authorization_code", "client_credentials"]
}

OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)

Dynamic Client Registration Protocol协议，解决OAuth客户端如何向授权服务器注册的问题。在没有DCRP协议时，OAuth客户端如果要向授权服务器进行注册，依赖人工配置，需要手动申请client_id和client_secret然后硬编码到OAuth客户端中，从而授权服务器可以正确识别一个OAuth客户端。

其大致授权过程如下：

1、客户端或开发者调用客户端注册端点，并附上客户端所需的注册元数据，如果授权服务器要求，则可选择包含初始访问令牌。

2、授权服务器注册客户端并返回：

客户端的注册元数据

client_id：在授权服务器上的唯一客户端标识

client_secret：客户端凭据，用于客户端证明自己的身份

OAuth 2.0 Protected Resource Metadata (RFC9728)

Protected Resource Metadata协议，通过在资源服务器上注册一个约定的获取元数据的端点，并在该端点返回关于该资源服务器的元数据配置，从而让客户端可以获取资源服务器支持的授权服务器、scope等信息，而无需在客户端中静态配置这些参数。

其工作流程如下：

1、客户端在没有提供访问令牌的情况下向受保护资源发起请求；

2、资源服务器响应中包含一个 WWW-Authenticate 头，其中包括受保护资源元数据的 URL；

3、客户端从此 URL 获取受保护资源的元数据；

4、服务器返回受保护的资源元数据；

5、客户端验证受保护的资源元数据，并根据RFC8414从资源元数据中的issuer标识构建授权服务器元数据 URL；

6、客户端请求获取授权服务器的元数据。

7、授权服务器根据RFC8414返回授权服务器元数据；

8、客户端配置用户代理请求授权服务器，开始用户授权流程；

9、授权完成后，授权服务器向客户端返回访问令牌等数据；

10、客户端通过访问令牌请求资源服务器；

11、资源服务器返回所请求资源。

MCP协议鉴权流程

MCP 2025-03-26

在该版本中，推荐基于HTTP(SSE, Streamable HTTP)传输的MCP Server实现规范描述的授权机制，该版本基于如下的协议规定了授权机制：

• OAuth 2.1 IETF DRAFT
• OAuth 2.0 Authorization Server Metadata (RFC8414)
• OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)

Authorization Server Metadata和Dynamic Client Registration Protocol标准，可以使得MCP Client在无需人工干预和预先配置的情况下，获取MCP Server的授权信息，并动态注册到MCP Server，因此协议推荐MCP Server和Client实现这些标准。

该版本的MCP授权步骤如下图所示：

1、MCP Client未携带访问令牌，访问MCP Server；

2、MCP Server拒绝访问请求，放回401 Unauthorized；

3、MCP Client根据Authorization Server Metadata协议的约定，访问MCP Server的元数据发现路径；

4、MCP Server将授权服务器元数据信息返回给MCP Client；

5、MCP Client根据Dynamic Client Registration Protocol的约定，访问MCP Server的注册端点；

6、MCP Server将客户端id和客户端凭据返回给MCP Client；

7、MCP Client为了防止中间人攻击，启动PKCE流程，生成code_verifier和code_challenge等信息；

8、MCP Client启动用户代理，携带code_challenge等信息将用户引导至授权页；

9、用户授权后，MCP Server会使用之前提供的重定向 URI（在请求中或客户端注册时提供）将用户代理重定向回MCP Client，重定向 URI 中包含授权码；

10、MCP Client通过包含上一步收到的授权码和其code_verifier，从MCP Server的令牌端点请求访问令牌。

11、MCP Server对客户端进行身份验证后，返回访问令牌和刷新令牌。

MCP最新Draft

在MCP 2025-03-26版本中，MCP Server被视为OAuth授权服务器，MCP Server开发者需要为每个MCP服务开发授权功能，导致开发MCP Server的成本较高而且MCP 服务开发者如果对授权不是特别了解的话，还容易引入安全问题。因此，在最新的Draft中，社区将MCP Server作为资源服务器，授权服务交给三方/现有的身份提供商/授权服务完成。

由于在最新MCP草案中，MCP Server只作为OAuth的资源服务器，因此，客户端如何发现授权服务器成为一个问题。草案通过引入Protected Resource Metadata协议，让资源服务器在客户端需要鉴权时，返回一个PRM文档，其中包含授权服务器的位置、授权的范围等信息，从而让MCP Client可以获得授权服务器的有关信息。

从而，最新的Draft相比MCP 2025-03-26版本，在授权机制上有如下的几个变化：

1、MCP Server作为资源服务器，授权功能由专门的授权服务器负责；

2、增加了OAuth 2.0 Protected Resource Metadata (RFC9728)的要求

其授权流程如下：

函数计算对MCP场景下Auth的支持

根据MCP Server是否包含授权实现，在函数计算上部署MCP Server可以分为三种方式：

一、MCP Server作为资源服务器和授权服务器，需要实现授权逻辑

二、MCP Server作为资源服务器，授权逻辑由三方服务实现

三、MCP Server作为资源服务器，授权由函数计算网关实现

由于前两种方式依赖MCP Server开发者自行实现，因此，在此处不再讨论，可以参考github上的公开实现。目前，函数计算网关还没有支持OAuth授权机制，在MCP集成场景下，我们提供了Bearer认证方式解决MCP 场景下的Auth问题。具体操作步骤如下：

1、登录阿里云控制台，跳转到函数计算3.0控制台后，选择创建函数，选择函数类型为“Web函数”，填写函数名称等参数后，选择函数运行时为MCP-Python-Python3.10，然后点击创建：

2、函数创建完成后，进入函数页面，在触发器配置上，选择默认的HTTP触发器，选择编辑后，修改触发器的认证方式为Bearer之后，配置选择默认，之后点击确认

其中tokenData部分就是用于客户端身份验证的Token数据，通过在Authorization Header中携带正确的Token数据，MCP Client就可以正确访问MCP Server

3、通过MCP Inspector验证MCP Server的功能：

在Transport Type中选择SSE，URL填入函数的触发器地址后，加上MCP SSE协议的/sse路径，在Authentication中，填写Header Name为Authorization，Bearer Token填写在函数触发器中配置的tokenData的值，点击Connect后，即可连接到MCP Server

连接成功后就可以查看MCP Server的Tool信息或者是调用Tool

如果配置的授权信息错误，则点击Connect会出现连接报错，此时需要检查配置的Authentication的Header Name和Bearer Token的值是否正确。

在Cursor等工具中使用部署在FC上开启Bearer认证的MCP服务时，如果工具不支持配置Bearer Token或者手动传递Authorization Header，可以通过社区的supergateway，将remote MCP Server暴露为本地的stdio，认证由supergateway负责，比如：

{
  "mcpServers": {
    "cursorExampleNpx": {
      "command": "npx",
      "args": [
        "-y",
        "supergateway",
        "--sse",
        "https://<替换为具体的函数地址>/sse",
        "--oauth2Bearer",
        "<替换为具体的Bearer Token数据>"
      ]
    }
  }
}

配置好后，就可以在Cursor中通过带认证信息的方式使用MCP Server了（注意要使用https协议，不要使用http协议）

通过函数计算网关进行权限认证，存在如下的优势：
1、节约MCP Server的开发成本，开发者专注自己的MCP服务的逻辑；
2、访问因为鉴权失败时，不会产生额外的费用，可以防止无效的调用请求。

总结

从MCP最早的2024-11-05版本不支持授权，到2025-03-26版本对OAuth 2.1的支持，再到最新Draft中对OAuth授权机制的进一步改进，MCP协议的安全性在不断完善，但是MCP Server支持Auth的开发成本、SDK对MCP Auth的跟进有滞后都使得开发者在安全的暴露自己的MCP服务上面临挑战。目前，在 MCP集成场景下，函数计算提供了 Bearer 认证方式解决 MCP 场景下的 Auth 问题。暂还没有支持OAuth 授权机制，我们会关注社区 OAuth 的进展。当然， 如果您有其他 restful API-KEY 的场景， 也可以使用函数计算提供的 Bearer 认证，Bearer认证支持 HTTP 触发器，并即将支持自定义域名。

参考

1.MCP Specification
2.supergateway
3.https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12
4.https://datatracker.ietf.org/doc/html/rfc8414
5.https://datatracker.ietf.org/doc/html/rfc7591
6.https://datatracker.ietf.org/doc/html/rfc9728