授权（Authorization）

​

引言

​

目的与范围

​

协议要求

• 使用基于 HTTP 的传输的实现**应当（SHOULD）**遵循本规范。
• 使用 STDIO 传输的实现**不应（SHOULD NOT）**遵循本规范，而应从环境中检索凭据。
• 使用其他替代传输的实现**必须（MUST）**遵循其协议既定的安全最佳实践。

​

标准合规性

• OAuth 2.1 IETF DRAFT（draft-ietf-oauth-v2-1-13）
• OAuth 2.0 Authorization Server Metadata（RFC8414）
• OAuth 2.0 Dynamic Client Registration Protocol（RFC7591）
• OAuth 2.0 Protected Resource Metadata（RFC9728）
• OAuth Client ID Metadata Documents（draft-ietf-oauth-client-id-metadata-document-00）

​

角色

​

概述

1. 授权服务器**必须（MUST）**为机密客户端和公开客户端实现带有适当安全措施的 OAuth 2.1。
2. 授权服务器和 MCP 客户端**应当（SHOULD）**支持 OAuth Client ID Metadata Documents（draft-ietf-oauth-client-id-metadata-document-00）。
3. 授权服务器和 MCP 客户端**可以（MAY）**支持 OAuth 2.0 Dynamic Client Registration Protocol（RFC7591）。
4. MCP 服务器**必须（MUST）实现 OAuth 2.0 Protected Resource Metadata（RFC9728）。MCP 客户端必须（MUST）**使用 OAuth 2.0 Protected Resource Metadata 进行授权服务器发现。
5. MCP 授权服务器**必须（MUST）**提供以下发现机制中的至少一种：
   • OAuth 2.0 Authorization Server Metadata（RFC8414）
   • OpenID Connect Discovery 1.0
   MCP 客户端**必须（MUST）**支持这两种发现机制，以获取与授权服务器交互所需的信息。

​

授权服务器发现

​

授权服务器位置

​

受保护资源元数据发现要求

1. WWW-Authenticate Header：在返回 401 Unauthorized 响应时，在 WWW-Authenticate HTTP header 的 resource_metadata 下包含资源元数据 URL，如 RFC9728 第 5.1 节 所述。
2. Well-Known URI：在 RFC9728 规定的 well-known URI 处提供元数据。这可以是：
   • 在服务器 MCP 端点的路径处：https://example.com/public/mcp 可以在 https://example.com/.well-known/oauth-protected-resource/public/mcp 托管元数据
   • 在根处：https://example.com/.well-known/oauth-protected-resource

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

​

授权服务器元数据发现

1. 带路径插入的 OAuth 2.0 Authorization Server Metadata：https://auth.example.com/.well-known/oauth-authorization-server/tenant1
2. 带路径插入的 OpenID Connect Discovery 1.0：https://auth.example.com/.well-known/openid-configuration/tenant1
3. 路径追加的 OpenID Connect Discovery 1.0：https://auth.example.com/tenant1/.well-known/openid-configuration

1. OAuth 2.0 Authorization Server Metadata：https://auth.example.com/.well-known/oauth-authorization-server
2. OpenID Connect Discovery 1.0：https://auth.example.com/.well-known/openid-configuration

​

授权服务器发现序列图

​

客户端注册方式

• Client ID Metadata Documents：当客户端和服务器没有事先关系时（最常见）
• 预注册（Pre-registration）：当客户端和服务器有既有关系时
• 动态客户端注册（Dynamic Client Registration）：用于向后兼容或特定要求

1. 如果客户端有可用的、针对该服务器的预注册客户端信息，则使用它
2. 如果授权服务器指示服务器支持 Client ID Metadata Documents（通过 OAuth Authorization Server Metadata 中的 client_id_metadata_document_supported），则使用它
3. 如果授权服务器支持动态客户端注册（通过 OAuth Authorization Server Metadata 中的 registration_endpoint），则将其作为回退使用
4. 如果没有其他选项可用，则提示用户输入客户端信息

​

Client ID Metadata Documents

​

实现要求

• 客户端**必须（MUST）**遵循 RFC 要求，将其元数据文档托管在一个 HTTPS URL 处
• client_id URL **必须（MUST）**使用 “https” 方案并包含一个路径组件，例如 https://example.com/client.json
• 元数据文档**必须（MUST）**至少包含以下属性：client_id、client_name、redirect_uris
• 客户端**必须（MUST）**确保元数据中的 client_id 值与文档 URL 完全匹配
• 客户端**可以（MAY）**使用 private_key_jwt 进行客户端认证（例如对令牌端点的请求），并配备如 Client ID Metadata Document 第 6.2 节 所述的适当 JWKS 配置

• **应当（SHOULD）**在遇到 URL 格式的 client_id 时获取元数据文档
• **必须（MUST）**校验所获取文档的 client_id 与该 URL 完全匹配
• **应当（SHOULD）**尊重 HTTP 缓存 header 缓存元数据
• **必须（MUST）**依据元数据文档中的 redirect URI 校验授权请求中呈现的 redirect URI
• **必须（MUST）**校验文档结构是有效的 JSON 并包含必需字段
• **应当（SHOULD）**遵循 Client ID Metadata Document 第 6 节 中的安全考量

​

示例元数据文档

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "client_uri": "https://app.example.com",
  "logo_uri": "https://app.example.com/logo.png",
  "redirect_uris": [
    "http://127.0.0.1:3000/callback",
    "http://localhost:3000/callback"
  ],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

​

Client ID Metadata Documents 流程

​

发现

{
  "client_id_metadata_document_supported": true
}

​

预注册

1. 硬编码一个专门供 MCP 客户端在与该授权服务器交互时使用的 client ID（以及在适用时的客户端凭据），或
2. 向用户呈现一个 UI，允许他们在自行注册一个 OAuth 客户端（例如通过服务器托管的配置界面）后输入这些详情。

​

动态客户端注册

​

Scope 选择策略

1. 使用 scope 参数——来自 401 响应中的初始 WWW-Authenticate header（如果提供）
2. 如果 scope 不可用，使用受保护资源元数据文档的 scopes_supported 中定义的所有 scope；如果 scopes_supported 未定义则省略 scope 参数。

​

授权流程步骤

​

Resource 参数实现

1. **必须（MUST）**同时包含在授权请求和令牌请求中。
2. **必须（MUST）**标识客户端打算将令牌用于的 MCP 服务器。
3. **必须（MUST）**使用 RFC 8707 第 2 节 中定义的 MCP 服务器规范 URI。

​

规范服务器 URI

• https://mcp.example.com/mcp
• https://mcp.example.com
• https://mcp.example.com:8443
• https://mcp.example.com/server/mcp（当需要路径组件来标识各个 MCP 服务器时）

• mcp.example.com（缺少方案）
• https://mcp.example.com#fragment（包含 fragment）

注意： 虽然 https://mcp.example.com/（带尾部斜杠）和 https://mcp.example.com（不带尾部斜杠）根据 RFC 3986 在技术上都是有效的绝对 URI，但实现**应当（SHOULD）**一致地使用不带尾部斜杠的形式以获得更好的互操作性，除非尾部斜杠对特定资源在语义上有意义。

&resource=https%3A%2F%2Fmcp.example.com

​

访问令牌用法

​

令牌要求

1. MCP 客户端**必须（MUST）**使用 OAuth 2.1 第 5.1.1 节 中定义的 Authorization 请求 header 字段：

Authorization: Bearer <access-token>

2. 访问令牌**不得（MUST NOT）**包含在 URI 查询串中

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

​

令牌处理

​

错误处理

​

Scope 质询处理

​

运行时 scope 不足错误

• HTTP 403 Forbidden 状态码（依据 RFC 6750 第 3.1 节）
• 带 Bearer 方案和附加参数的 WWW-Authenticate header：
  • error="insufficient_scope" —— 指示授权失败的具体类型
  • scope="required_scope1 required_scope2" —— 指定操作所需的最小 scope
  • resource_metadata —— 受保护资源元数据文档的 URI（与 401 响应保持一致）
  • error_description（可选）—— 错误的人类可读描述

• 最小方式：包含特定操作所需的新 scope。如果任何既有已授予 scope 也是必需的，也一并包含，以防止客户端失去先前授予的权限。
• 推荐方式：同时包含既有相关 scope 和新需要的 scope，以防止客户端失去先前授予的权限
• 扩展方式：包含既有 scope、新需要的 scope，以及常常一起工作的相关 scope

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                         scope="files:read files:write user:profile",
                         resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         error_description="Additional file write permission required"

​

升级授权流程

1. 解析错误信息——来自授权服务器响应或 WWW-Authenticate header
2. 确定所需 scope——如 Scope 选择策略 中所述。
3. 发起（重新）授权——使用所确定的 scope 集
4. 重试原始请求——以新授权重试，次数不超过若干次，并将其视为永久性授权失败

​

安全考量

​

令牌受众绑定与校验

• MCP 客户端**必须（MUST）**按 Resource 参数实现 一节所规定，在授权和令牌请求中包含 resource 参数
• MCP 服务器**必须（MUST）**校验呈现给它们的令牌是专门为其使用而签发的

​

令牌窃取

​

通信安全

1. 所有授权服务器端点**必须（MUST）**通过 HTTPS 提供。
2. 所有 redirect URI **必须（MUST）**要么是 localhost 要么使用 HTTPS。

​

授权码保护

• OAuth 2.0 Authorization Server Metadata：如果 code_challenge_methods_supported 缺失，则授权服务器不支持 PKCE，MCP 客户端**必须（MUST）**拒绝继续。
• OpenID Connect Discovery 1.0：虽然 OpenID Provider Metadata 未定义 code_challenge_methods_supported，但此字段通常被 OpenID 提供方包含。MCP 客户端**必须（MUST）验证提供方元数据响应中 code_challenge_methods_supported 的存在。如果该字段缺失，MCP 客户端必须（MUST）**拒绝继续。

​

开放重定向

​

Client ID Metadata Document 安全

​

授权服务器滥用防护

​

Localhost 重定向 URI 风险

1. 提供合法客户端的元数据 URL 作为其 client_id
2. 绑定到任意 localhost 端口，并提供该地址作为 redirect_uri
3. 在用户批准时通过重定向接收授权码

• **应当（SHOULD）**对仅 localhost 的 redirect URI 显示额外警告
• **可以（MAY）**为增强安全性要求额外的证明机制
• **必须（MUST）**在授权期间清晰地显示 redirect URI 主机名

​

信任策略

• 受信任域名的允许列表（用于受保护的服务器）
• 接受任何 HTTPS client_id（用于开放的服务器）
• 对未知域名的信誉检查
• 基于域名年龄或证书校验的限制
• 显著地显示 CIMD 和其他关联的客户端主机名以防止钓鱼

​

混淆代理问题

​

访问令牌权限限制

1. Audience 校验失败。 当 MCP 服务器不验证令牌是专门为它准备的（例如，通过 RFC9068 中提到的 audience claim）时，它可能接受最初为其他服务签发的令牌。这打破了一个基本的 OAuth 安全边界，允许攻击者跨不同于预期的服务重用合法令牌。
2. 令牌透传。 如果 MCP 服务器不仅接受具有不正确 audience 的令牌，还将这些未修改的令牌转发给下游服务，它就可能引发”混淆代理”问题，其中下游 API 可能错误地信任该令牌，仿佛它来自 MCP 服务器，或假设该令牌已被上游 API 校验。有关更多细节，参见安全最佳实践指南的令牌透传一节。

​

MCP 授权扩展

• 可选（Optional） —— 实现可以选择采用这些扩展
• 附加（Additive） —— 扩展不修改或破坏核心协议功能；它们在保留核心协议行为的同时添加新能力
• 可组合（Composable） —— 扩展是模块化的，被设计为无冲突地协同工作，允许实现同时采用多个扩展
• 独立版本化（Versioned independently） —— 扩展遵循核心 MCP 版本化周期，但可按需采用独立的版本化