11.1 OAuth 2.1 角色与 MCP 的承担方式

文档摘要

11.1 OAuth 2.1 角色与 MCP 的承担方式本节摘要:第 11 章讲认证授权,本节先理清理论——OAuth 2.1 的四个角色,以及 MCP 服务端如何同时承担其中两个。OAuth 2.1 是一套成熟的授权框架,定义了「资源所有者、客户端、授权服务器、资源服务器」四个角色。MCP 服务端的特殊之处在于:它同时是授权服务器(签发令牌)和资源服务器(校验令牌、保护资源)。理解这个「双重承担」,你才能理解第 11 章后续的实现思路。一、OAuth 2.1 的四个角色 OAuth 2.

11.1 OAuth 2.1 角色与 MCP 的承担方式

本节摘要:第 11 章讲认证授权,本节先理清理论——OAuth 2.1 的四个角色,以及 MCP 服务端如何同时承担其中两个。OAuth 2.1 是一套成熟的授权框架,定义了「资源所有者、客户端、授权服务器、资源服务器」四个角色。MCP 服务端的特殊之处在于:它同时是授权服务器(签发令牌)和资源服务器(校验令牌、保护资源)。理解这个「双重承担」,你才能理解第 11 章后续的实现思路。

一、OAuth 2.1 的四个角色

OAuth 2.1 定义了四个标准角色:

角色	是谁	干什么
资源所有者(Resource Owner)	最终用户	拥有数据,能授权访问
客户端(Client)	要访问数据的应用	用令牌访问资源
授权服务器(Authorization Server)	签发令牌的服务	验证用户、签发/刷新令牌
资源服务器(Resource Server)	持有数据的服务	校验令牌、返回受保护资源

经典 OAuth 流程:


   资源所有者(用户)
        │
        │ 1. 授权
        ▼
   授权服务器 ──── 2. 签发令牌 ────► 客户端
                                         │
                                         │ 3. 持令牌请求
                                         ▼
                                    资源服务器
                                         │
                                         │ 4. 校验令牌
                                         ▼
                                    返回受保护资源

这四个角色在标准 OAuth 里通常分属不同服务,但 MCP 把它们合并到了服务端。

二、MCP 服务端的双重承担

MCP 服务端的特殊之处:它同时是授权服务器和资源服务器。


标准 OAuth(四个服务):
   授权服务器(独立)
   资源服务器(独立)
   客户端(独立)
   用户(浏览器)

MCP 服务端(合并承担):
   ┌─────────────────────────────────┐
   │       MCP 服务端                │
   │  ┌───────────────────────────┐  │
   │  │ 授权服务器逻辑             │  │  ← 签发令牌
   │  │ - 授权码流                 │  │
   │  │ - 令牌签发/刷新            │  │
   │  └───────────────────────────┘  │
   │  ┌───────────────────────────┐  │
   │  │ 资源服务器逻辑             │  │  ← 校验令牌
   │  │ - Bearer 令牌中间件        │  │
   │  │ - 保护工具/资源            │  │
   │  └───────────────────────────┘  │
   │  ┌───────────────────────────┐  │
   │  │ 你的业务(工具/资源/提示词)│  │
   │  └───────────────────────────┘  │
   └─────────────────────────────────┘

也就是说:一个 MCP 服务端内含两套 OAuth 逻辑——既签发令牌(授权服务器),又校验令牌保护资源(资源服务器)。

三、为什么 MCP 合并承担

为什么不像标准 OAuth 那样把授权服务器独立出来?几个理由:

理由	说明
部署简单	一个服务搞定一切,不用维护多个服务
降低门槛	MCP 服务端作者无需另搭授权服务器
自包含	服务端自带认证,不依赖外部 IdP
够用	对多数 MCP 场景,内置授权足够

这个设计让 MCP 服务端自包含——你不用为了加认证再搭一个 Keycloak、Auth0 这样的独立 IdP。SDK 提供了授权服务器的骨架,你实现几个存储接口即可。

⚠️ 注意:MCP 的「合并承担」是默认形态,不是唯一形态。如果你已有企业 IdP(如公司 SSO),MCP 也支持对接外部 IdP(通过身份断言扩展,第 11.5 节)。但对「从零搭一个受保护的 MCP 服务」,合并承担是最省事的选择。

四、客户端在 MCP OAuth 里的角色

MCP 客户端在 OAuth 里扮演「客户端」角色——它持令牌访问服务端:


MCP 客户端(持令牌)
   │
   │ 1. 向 MCP 服务端的授权服务器请求令牌
   │    (走授权码流,浏览器跳转)
   ▼
MCP 服务端(授权服务器)签发令牌
   │
   │ 2. 客户端持令牌调工具/读资源
   ▼
MCP 服务端(资源服务器)校验令牌,返回受保护资源

注意:MCP 客户端既向服务端要令牌,又持令牌访问服务端——两端是同一个 MCP 服务端,只是逻辑角色不同(授权服务器 vs 资源服务器)。

五、授权码流:最常用的流程

OAuth 2.1 最常用的是授权码流(Authorization Code Flow),适用于有用户参与的场景:


1. 客户端引导用户浏览器跳转到服务端的授权页
   https://mcp.example.com/authorize?client_id=...&redirect_uri=...

2. 用户在授权页登录、同意授权

3. 服务端把授权码重定向回客户端的 redirect_uri
   https://client.example.com/callback?code=AUTH_CODE

4. 客户端用授权码换令牌(POST /token)
   {grant_type: authorization_code, code: AUTH_CODE}

5. 服务端返回访问令牌 + 刷新令牌
   {access_token: "...", refresh_token: "...", expires_in: 3600}

6. 客户端持访问令牌调 MCP 方法
   Authorization: Bearer <access_token>

这个流程是 OAuth 的核心,MCP 的授权服务器骨架替你实现了大部分(第 11.2 节详讲)。

六、本节的认知收获

读完本节,你应该建立这两个心智模型:

OAuth 四角色:资源所有者(用户)、客户端、授权服务器、资源服务器——理解它们各自干什么。
MCP 服务端双重承担:同时是授权服务器(签发)和资源服务器(校验),这让 MCP 服务端自包含,不依赖外部 IdP。

带着这两个模型,第 11 章后续会分别讲「服务端怎么实现授权服务器 + 资源服务器保护」(11.2)、「客户端怎么持令牌访问」(11.3)、「机器到机器的客户端凭证」(11.4)、「对接外部 IdP 的身份断言」(11.5)。

本节要点回顾

OAuth 2.1 四角色:资源所有者、客户端、授权服务器、资源服务器。
MCP 服务端同时承担授权服务器与资源服务器——这是它的特殊之处。
合并承担的理由:部署简单、降低门槛、自包含、够用。
MCP 客户端扮演 OAuth 客户端角色,持令牌访问服务端。
授权码流是最常用流程:浏览器跳转 → 用户同意 → 授权码 → 换令牌 → 持令牌访问。
MCP 服务端可对接外部 IdP(身份断言扩展),合并承担是默认非唯一形态。

角色清楚了,下一节讲服务端怎么实现授权服务器。