背景
Cloud Native
在系列文章第 4 篇 《MCP Server On FC 之旅 4: 长连接闲置计费最高降低 87% 成本的技术内幕" data-itemshowtype="0" linktype="text" data-linktype="2">MCP Server On FC 之旅 4: 长连接闲置计费最高降低 87% 成本的技术内幕》，我们解构了 FC 在 MCP 场景下通过闲置计费能力为用户降本的技术内幕和使用方式。本文将从 Auth 的角度，介绍 MCP 协议对 Auth 的支持以及函数计算为适配 MCP 协议 Auth 目前提供的能力和之后会开放的能力。
MCP 授权机制
Cloud Native
MCP 在最开始的 2024-11-05 版本中并没有支持授权，在 2025-03-26 中，MCP 协议支持了基于 OAuth2.1 的授权机制，在最新的 MCP Draft 中，社区对基于 OAuth 2.1 的授权协议内容进行了调整，三个协议版本的授权协议基于的 OAuth 标准见下表。本节会先简单介绍 MCP 协议所使用到的几个 OAuth 协议/子协议，然后分别介绍 MCP 2025-03-26 版本和最新 Draft 的授权过程。
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 OKContent-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 的支持
Cloud Native
根据 MCP Server 是否包含授权实现，在函数计算上部署 MCP Server 可以分为三种方式：
一、MCP Server 作为资源服务器和授权服务器，需要实现授权逻辑。
二、MCP Server 作为资源服务器，授权逻辑由三方服务实现。
三、MCP Server 作为资源服务器，授权由函数计算网关实现。
由于前两种方式依赖 MCP Server 开发者自行实现，因此，在此处不再讨论，可以参考 github 上的公开实现。目前，函数计算网关还没有支持 OAuth 授权机制，在 MCP 集成场景下，我们提供了 Bearer 认证方式解决 MCP 场景下的 Auth 问题。
具体操作步骤如下：
1. 登录阿里云控制台，跳转到函数计算 3.0 控制台【1】后，选择创建函数，选择函数类型为“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. 访问因为鉴权失败时，不会产生额外的费用，可以防止无效的调用请求。
总结
Cloud Native
从 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 触发器，并即将支持自定义域名。
