协议版本: draft

​
简介

​
目的与范围

Model Context Protocol 在传输层提供授权功能，使得 MCP 客户端能够代表资源所有者向受限的 MCP 服务器发出请求。本规范定义了基于 HTTP 传输的授权流程。

​
协议要求

授权对于 MCP 实现来说是可选项目。当被支持时：
  • 采用基于HTTP传输的实现应该符合本规范。
  • 使用STDIO传输的实现不应该遵循此规范，而应从环境中获取凭据。
  • 使用替代传输方式的实现必须遵循其协议的既定安全最佳实践。

​
标准合规性

此授权机制基于以下已建立的规范，但实现了它们功能的一个选定子集，以确保安全性和互操作性，同时保持简洁性：

​
授权流程

​
角色

一个受保护的MCP服务器充当OAuth 2.1 资源服务器， 能够使用访问令牌接收和响应受保护的资源请求。 一个 MCP客户端 充当 OAuth 2.1 client， 代表资源所有者进行受保护资源请求。 授权服务器负责与用户交互（如有必要），并为在 MCP 服务器上使用而发放访问令牌。授权服务器的实现细节超出了本规范的范围。它可以托管在资源服务器上，也可以作为独立实体存在。授权服务器发现部分规定了 MCP 服务器如何向客户端指示其对应授权服务器的位置。

​
概览

  1. 授权服务器必须实现支持机密客户端和公共客户端的OAuth 2.1，并采取适当的安全措施。
  2. 授权服务器与MCP客户端应当支持OAuth 2.0动态客户端注册协议(RFC7591)。
  3. MCP服务器必须实现OAuth 2.0受保护资源元数据（RFC9728）。 MCP客户端必须使用OAuth 2.0受保护资源元数据进行授权服务器发现。
  4. MCP authorization servers 必须 提供至少以下一种发现机制: MCP clients 必须 同时支持两种发现机制，以获取与授权服务器交互所需的信息。

​
授权服务器发现

本节描述了MCP服务器向MCP客户端广告其关联授权服务器的机制，以及MCP客户端确定授权服务器端点和支持功能的发现过程。

​
认证服务器位置

MCP servers 必须 实现 OAuth 2.0 保护资源元数据 (RFC9728) 规范以指示授权服务器的位置。MCP server 返回的保护资源元数据文档 必须 包含 包含至少一个授权服务器的 authorization_servers 字段。 authorization_servers的具体使用不在本规范范围内；实施者应参考OAuth 2.0受保护资源元数据（RFC9728）来获取实施细节的指导。 实现者应注意，受保护资源元数据文档可以定义多个授权服务器。选择使用哪个授权服务器的责任在于 MCP 客户端，需遵循 RFC9728 Section 7.6 “Authorization Servers” 中指定的指导原则。 MCP servers 必须 在返回 401 未授权 时使用 HTTP 头部 WWW-Authenticate 来指示资源服务器元数据 URL 的位置, 正如 RFC9728 Section 5.1 “WWW-Authenticate Response” 中所述. MCP客户端必须能够解析WWW-Authenticate标头并正确响应来自MCP服务器的HTTP 401 Unauthorized响应。

​
服务器元数据发现

为解决不同颁发者URL格式问题，并确保与OAuth 2.0授权服务器元数据和OpenID Connect Discovery 1.0规范的双向兼容性，MCP客户端必须在发现授权服务器元数据时尝试多个well-known端点。 发现方法基于RFC8414 第3.1节"授权服务元数据请求"用于OAuth 2.0授权服务元数据发现，以及RFC8414 第5节"兼容性说明"用于OpenID Connect Discovery 1.0的互操作性。 对于包含路径组件的颁发者URL（例如：https://auth.example.com/tenant1），客户端必须按以下优先级顺序尝试端点：
  1. OAuth 2.0 授权服务器元数据带路径插入: 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
对于没有路径组件的颁发者URL(例如: https://auth.example.com), 客户端必须尝试:
  1. OAuth 2.0 授权服务器元数据: https://auth.example.com/.well-known/oauth-authorization-server
  2. OpenID Connect Discovery 1.0: https://auth.example.com/.well-known/openid-configuration

​
序列图

以下图表概述了一个示例流程：

​
动态客户端注册

MCP clients and authorization servers 应该支持 OAuth 2.0动态客户端注册协议RFC7591 以允许MCP客户端无需用户交互即可获取OAuth客户端ID。这为客户端提供了一种 标准化方式来自动向新授权服务器注册，这对于MCP至关重要，因为：
  • 客户端可能并不预先知道所有可能的MCP服务器及其授权服务器。
  • 手动注册会给用户带来不便。
  • 它能够无缝连接新的MCP服务器及其授权服务器。
  • 授权服务器可以实现自己的注册策略。
任何不支持动态客户端注册的授权服务器需要提供替代方案以获取客户端ID（以及如果适用的客户端凭据）。对于这些授权服务器，MCP客户端将必须选择以下任一方式：
  1. 为该MCP客户端与授权服务器交互时专门硬编码一个客户端ID（以及适用的客户端凭据），或
  2. 向用户提供一个界面，让他们在自行注册OAuth客户端后（例如通过服务器托管的配置界面）输入这些详细信息。

​
授权流步骤

完整的权限认证流程如下：

​
资源参数实现

MCP客户端必须按照RFC 8707定义的OAuth 2.0资源指示符实现，以明确指定请求令牌的目标资源。resource参数：
  1. 必须 同时包含在授权请求和令牌请求中。
  2. 必须识别客户端计划使用令牌的 MCP 服务器。
  3. 必须使用 RFC 8707 第 2 节中定义的 modelcontextprotocol 服务器的规范 URI。
标准服务器统一资源标识符
就本规范而言，MCP服务器规范URI的定义遵循 RFC 8707第2节中规定的资源标识符，并与 RFC 9728中的resource参数保持一致。 MCP 客户端应该提供其打算访问的 MCP 服务器的最具体 URI，遵循 RFC 8707 中的指导。虽然规范形式使用小写的方案和主机组件，但实现应该接受大写的方案和主机组件，以提高鲁棒性和互操作性。 有效规范URI示例：
  • https://mcp.example.com/mcp
  • https://mcp.example.com
  • https://mcp.example.com:8443
  • https://mcp.example.com/server/mcp（当需要路径组件来识别独立的MCP服务时）
无效规范URI的示例：
  • mcp.example.com (缺少协议头)
  • https://mcp.example.com#fragment (包含片段)
注意： 虽然根据RFC 3986，https://mcp.example.com/（带末尾斜杠）和https://mcp.example.com（不带末尾斜杠）在技术上都属于有效的绝对URI，但实现应该始终使用不带末尾斜杠的形式以确保更好的互操作性，除非末尾斜杠对所指定的资源具有语义上的重要性。
例如，如果访问位于https://mcp.example.com的MCP服务器，授权请求将包含： 
&resource=https%3A%2F%2Fmcp.example.com
MCP客户端无论授权服务器是否支持，必须发送此参数。

​
访问令牌使用情况

​
令牌要求

向MCP服务器发起请求时的访问令牌处理必须符合OAuth 2.1第5章"资源请求"中定义的要求。具体来说：
  1. MCP 客户端必须使用在 OAuth 2.1 第5.1.1章节中定义的授权请求头字段:
Authorization: Bearer <access-token>
注意授权必须包含在每个从客户端到服务器的HTTP请求中， 即使它们是同一逻辑会话的一部分。
  1. 访问令牌不允许包含在URI查询字符串中
示例请求： 
GET /mcp HTTP/1.1
Host: mcp.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

​
令牌处理

MCP servers, acting in their role as an OAuth 2.1 resource server, 必须 validate access tokens as described in OAuth 2.1 Section 5.2. MCP servers 必须 validate that access tokens were issued specifically for them as the intended audience, according to RFC 8707 Section 2. If validation fails, servers 必须 respond according to OAuth 2.1 Section 5.3 error handling requirements. Invalid or expired tokens 必须 receive a HTTP 401 response. MCP 客户端严禁发送除MCP服务器授权服务器颁发的令牌以外的令牌到MCP服务器。 授权服务器必须仅接受对其自身资源有效的令牌。 MCP servers 严禁 接受或传输任何其他令牌。

​
错误处理

Servers 必须 为授权错误返回适当的 HTTP 状态码：
状态码描述使用
401未授权需要授权或令牌无效
403禁止访问无效范围或权限不足
400错误的请求格式错误的授权请求

​
安全注意事项

实施 必须 遵循 OAuth 2.1 的安全最佳实践，如 OAuth 2.1 第7节“安全注意事项” 中所述。

​
令牌受众绑定与验证

RFC 8707 资源指示器通过将令牌绑定到其预期受众，提供关键的安全性优势 当授权服务器支持该能力时。为了支持当前和未来的采用：
  • MCP 客户端必须在授权和令牌请求中包含 resource 参数，具体按照资源参数实施章节中的规定
  • MCP 服务器 必须 验证提供给它们的令牌是专门为其使用而签发的
安全最佳实践文档 概述了令牌受众验证为何至关重要以及为何明确禁止令牌透传。

​
令牌窃取

攻击者获取客户端存储的令牌，或服务器上缓存或记录的令牌后，就能够通过看似对资源服务器合法的请求访问受保护资源。 客户端和服务端必须实现安全的令牌存储并遵循OAuth最佳实践， 如OAuth 2.1, Section 7.1中所述。 授权服务器 应该 签发短期访问令牌以减少令牌泄露的影响。 对于公共客户端，授权服务器 必须 轮换刷新令牌，详见OAuth 2.1 章节 4.3.1 "令牌端点扩展"。

​
通信安全

实现 必须 遵循 OAuth 2.1 第1.5节“通信安全”. 具体来说：
  1. 所有授权服务器端点必须通过HTTPS提供服务。
  2. 所有重定向URI必须是localhost或使用HTTPS。

​
授权码保护

攻击者已获得授权响应中包含的授权代码后，可能会尝试兑换该授权代码以获取访问令牌，或以其他方式利用该授权代码。 （更多描述详见OAuth 2.1 第7.5节） 为减轻此风险，MCP客户端必须根据OAuth 2.1 第7.5.2节实施PKCE，并在继续授权前必须验证PKCE支持。 PKCE通过要求客户端创建秘密验证器-挑战对，有助于防止授权代码拦截和注入攻击，确保只有原始请求者才能将授权代码兑换为令牌。 MCP客户端在技术可行的情况下必须使用S256代码挑战方法，如OAuth 2.1 第4.1.1节所要求的。 由于OAuth 2.1和PKCE规范未定义客户端发现PKCE支持的机制，MCP客户端必须依赖授权服务器元数据验证此能力：
  • OAuth 2.0 认证服务元数据：若code_challenge_methods_supported未提供，则认证服务器不支持PKCE，MCP客户端必须拒绝继续操作。
  • OpenID Connect Discovery 1.0: 虽然OpenID 提供方元数据未定义 code_challenge_methods_supported，但该字段通常由 OpenID 提供方包含。MCP 客户端必须验证提供方元数据响应中是否存在 code_challenge_methods_supported。如果该字段缺失，MCP 客户端必须拒绝继续执行。
提供 OpenID Connect Discovery 1.0 的授权服务器必须在其元数据中包含 code_challenge_methods_supported 以确保与 MCP 的兼容性。

​
开放重定向

攻击者可能构造恶意的重定向URI，将用户引导至钓鱼网站。 MCP clients 必须在授权服务器上注册重定向URI。 认证服务器 必须 根据预先注册的值验证确切的回调URI，以防止重定向攻击。 MCP clients 应该 在授权码流程中使用并验证状态参数,并丢弃任何不包含原始状态或与原始状态不匹配的结果。 授权服务器 必须 采取预防措施，以防止将智能体重定向到不受信任的URI，遵循 OAuth 2.1 第7.12.2节中提出的建议 授权服务器 应该 仅在信任重定向URI时自动重定向用户代理。如果URI不受信任，授权服务器可以通知用户并依赖用户做出正确的决定。

​
Confused Deputy 问题

攻击者可以利用MCP服务器作为第三方API的中介，导致混淆代理漏洞。 通过使用被盗的授权码，他们可以在未经用户同意的情况下获取访问令牌。 MCP proxy servers using static client IDs 必须 obtain user consent for each dynamically registered client before forwarding to third-party authorization servers (which may require additional consent).

​
访问令牌权限限制

攻击者可以获取未经授权的访问或通过其他方式危及 MCP 服务器的安全，如果该服务器接受为其他资源颁发的令牌。 此漏洞具有两个关键维度：
  1. 受众验证失败。 当一个 MCP 服务器不验证令牌是否特意为它所签发（例如，通过 RFC9068 中提到的受众声明），它可能会接受原本为其他服务签发的令牌。这会突破基本的 OAuth 安全边界，让攻击者能够跨不同服务重用合法令牌，超出原本的预期范围。
  2. 令牌透传。 如果MCP服务器不仅接受含错误受众声明的令牌，还将这些未经修改的令牌转发给下游服务，则可能引发「混淆代理人」问题——下游API可能会错误地将该令牌信任为来自MCP服务器，或假设该令牌已通过上游API的验证。更多详细信息请参阅安全最佳实践指南中的令牌透传章节。
MCP服务器必须在处理请求前验证访问令牌，确保该访问令牌是专门为MCP服务器颁发的，并采取所有必要措施确保不会向未授权方返回任何数据。 MCP服务器 必须 遵循 OAuth 2.1 - 第5.2节 中的指导方针来验证入站令牌。 MCP服务器必须仅接受专门为其生成的令牌，并且必须拒绝那些未将其包含在受众声明中的令牌，或以其他方式验证它们是否为令牌的预期接收者。有关详细信息，请参阅Security Best Practices Token Passthrough section。 如果MCP服务器向上游API发起请求，它可能作为OAuth客户端与它们交互。在上游API使用的访问令牌是由上游授权服务器颁发的独立令牌。MCP服务器严禁透传从MCP客户端收到的令牌。 MCP 客户端必须实现并使用 resource 参数（定义于 RFC 8707 - OAuth 2.0 资源指标），以明确指定请求令牌的目标资源。这一要求符合 RFC 9728 第 7.4 节的建议，确保访问令牌绑定到其预期资源，且无法在不同服务间被误用。