【MCP】MCP 协议 (2025-06-18)之认证

​
引言
​

目的和范围

模型上下文协议在传输级别提供授权功能，使MCP客户端能够代表资源所有者向受限制的MCP服务器发出请求。本规范定义了基于HTTP的传输的授权流。
​

协议要求

授权对于MCP实施是可选的。支持时：

• 使用基于HTTP的传输的实现应该符合此规范。
• 使用STDIO传输的实现不应遵循此规范，而应从环境中检索凭据。
• 使用替代传输的实现必须遵循其协议的既定安全最佳实践。
  ​

标准符合性

这种授权机制基于下面列出的既定规范，但实现了其功能的选定子集，以确保安全性和互操作性，同时保持简单性：

• OAuth 2.1 IETF草案（DRAFT-IETF-OAuth-v2-1-13）
• OAuth 2.0授权服务器元数据（RFC8414）
• OAuth 2.0动态客户端注册协议（RFC7591）
• OAuth 2.0受保护资源元数据（RFC9728）
  ​

授权流程
​

角色

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

概述

• 授权服务器必须为机密和公共客户端实施OAuth 2.1，并采取适当的安全措施。
• 授权服务器和MCP客户端应支持OAuth 2.0动态客户端注册协议（RFC7591）。
• MCP服务器必须实现OAuth 2.0受保护资源元数据（RFC9728）。MCP客户端必须使用OAuth 2.0受保护的资源元数据进行授权服务器发现。
• 授权服务器必须提供OAuth 2.0授权服务器元数据（RFC8414）。MCP客户端必须使用OAuth 2.0授权服务器元数据。
  ​

授权服务器发现

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

授权服务器位置

MCP服务器必须实现OAuth 2.0受保护资源元数据（RFC9728）规范，以指示授权服务器的位置。MCP服务器返回的受保护资源元数据文档必须包含至少包含一个授权服务器的authorization_servers字段。

授权服务器（authorization_servers）的具体使用超出了本规范的范围；实施者应参考OAuth 2.0受保护资源元数据（RFC9728）以获取实施细节的指导。

实施者应该注意，受保护的资源元数据文档可以定义多个授权服务器。选择使用哪个授权服务器的责任在于MCP客户端，遵循RFC9728第7.6节“授权服务器”中规定的指导方针。

MCP服务器在返回401 Unauthorized时必须使用HTTP标头WWW-Authenticate来指示资源服务器元数据URL的位置，如RFC9728第5.1节“WWW身份验证响应”所述。

MCP客户端必须能够解析WWW-Authenticate标头，并对来自MCP服务器的HTTP 401未经授权的响应做出适当的响应。
​

服务器元数据发现

MCP客户端必须遵循OAuth 2.0授权服务器元数据RFC8414规范，以获取与授权服务器交互所需的信息。
​

序列图

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

​
动态客户端注册

MCP客户端和授权服务器应支持OAuth 2.0动态客户端注册协议RFC7591，以允许MCP客户端在无需用户交互的情况下获取OAuth客户端ID。这为客户端自动向新的授权服务器注册提供了一种标准化的方式，这对MCP至关重要，因为：

• 客户端可能无法提前知道所有可能的MCP服务器及其授权服务器。
• 手动注册会给用户带来摩擦。
• 它实现了与新MCP服务器及其授权服务器的无缝连接。
• 授权服务器可以实现自己的注册策略。

任何不支持动态客户端注册的授权服务器都需要提供其他方法来获取客户端ID（以及客户端凭据，如果适用）。对于其中一个授权服务器，MCP客户端必须：

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

授权流程步骤

完整的授权流程如下：

​
资源参数实现

MCP客户端必须实现RFC 8707中定义的OAuth 2.0的资源指示符，以明确指定请求令牌的目标资源。资源参数：

• 必须包含在授权请求和令牌请求中。
• 必须识别客户端打算使用令牌的MCP服务器。
• 必须使用RFC 8707第2节中定义的MCP服务器的规范URI。

规范服务器URI

为了本规范的目的，MCP服务器的规范URI被定义为RFC 8707第2节中指定的资源标识符，并与RFC 9728中的资源参数对齐。
MCP客户端应按照RFC 8707中的指导，为他们打算访问的MCP服务器提供最具体的URI。虽然规范形式使用小写方案和主机组件，但实现应该接受大写方案和主机元素，以实现健壮性和互操作性。
有效规范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（包含片段）

注：虽然两者https://mcp.example.com/（带尾随斜线）和https://mcp.example.com根据RFC 3986，（没有尾随斜线）在技术上是有效的绝对URI，实现应该一致地使用没有尾随斜线的形式，以获得更好的互操作性，除非尾随斜线对特定资源具有语义意义。
例如，如果在以下位置访问MCP服务器https://mcp.example.com，授权请求将包括：

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

MCP客户端必须发送此参数，无论授权服务器是否支持它。
 

访问令牌使用情况
​
令牌要求

向MCP服务器发出请求时的访问令牌处理必须符合OAuth 2.1第5节“资源请求”中定义的要求。明确地：
MCP客户端必须使用OAuth 2.1第5.1.1节中定义的授权请求头字段：

Authorization: Bearer <access-token>

请注意，从客户端到服务器的每个HTTP请求中都必须包含授权，即使它们是同一逻辑会话的一部分。
访问令牌不得包含在URI查询字符串中
请求示例：

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

令牌处理

MCP服务器作为OAuth 2.1资源服务器，必须按照OAuth 2.1第5.2节所述验证访问令牌。根据RFC 8707第2节，MCP服务器必须验证访问令牌是专门为他们作为预期受众发放的。如果验证失败，服务器必须根据OAuth 2.1第5.3节的错误处理要求做出响应。无效或过期的令牌必须接收HTTP 401响应。
MCP客户端不得向MCP服务器发送除MCP服务器授权服务器颁发的令牌以外的令牌。
授权服务器必须只接受对其自身资源有效的令牌。
MCP服务器不得接受或传输任何其他令牌。

​
错误处理

服务器必须为授权错误返回相应的HTTP状态代码：

状态代码描述用法
401需要未经授权的授权或令牌无效
403禁止无效作用域或权限不足
400错误请求授权请求格式错误
​

安全考虑

实现必须遵循OAuth 2.1第7节中规定的OAuth 2.1安全最佳实践。“安全考虑”。
​
 

令牌受众绑定和验证

RFC 8707资源指示器通过在授权服务器支持该功能时将令牌绑定到其预期受众，提供了关键的安全优势。为了实现当前和未来的采用：

• MCP客户端必须在授权和令牌请求中包含资源参数，如资源参数实现部分所述
• MCP服务器必须验证提供给他们的令牌是专门为他们使用而颁发的

安全最佳实践文档（https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices#token-passthrough）概述了为什么令牌受众验证至关重要，以及为什么明确禁止令牌传递。
​
 

令牌盗窃

获得客户端存储的令牌或服务器上缓存或登录的令牌的攻击者可以通过对资源服务器看似合法的请求访问受保护的资源。
客户端和服务器必须实现安全的令牌存储，并遵循OAuth 2.1第7.1节中概述的OAuth最佳实践。
授权服务器应发出短期访问令牌，以减少泄漏令牌的影响。对于公共客户端，授权服务器必须按照OAuth 2.1第4.3.1节“令牌端点扩展”中的描述轮换刷新令牌。
​

通信安全

实现必须遵循OAuth 2.1第1.5节“通信安全”。
明确地：

• 所有授权服务器端点必须通过HTTPS提供服务。
• 所有重定向URI必须是localhost或使用HTTPS。

授权码保护

获得授权响应中包含的授权码访问权限的攻击者可以尝试将授权码兑换为访问令牌，或以其他方式使用授权码。（详见OAuth 2.1第7.5节）
为了缓解这种情况，MCP客户端必须根据OAuth 2.1第7.5.2节实现PKC。PKCE要求客户端创建一个秘密验证器挑战对，确保只有原始请求者可以将授权码交换为令牌，从而有助于防止授权码拦截和注入攻击。
 

打开重定向

攻击者可能会精心制作恶意重定向URI，将用户定向到钓鱼网站。
MCP客户端必须在授权服务器上注册重定向URI。
授权服务器必须根据预先注册的值验证精确的重定向URI，以防止重定向攻击。
MCP客户端应使用并验证授权码流中的状态参数，并丢弃任何不包括或与原始状态不匹配的结果。
授权服务器必须采取预防措施，防止将用户代理重定向到不受信任的URI，遵循OAuth 2.1第7.12.2节中的建议
授权服务器只应在信任重定向URI的情况下自动重定向用户代理。如果URI不受信任，授权服务器可能会通知用户并依靠用户做出正确的决定。

困惑的副问题

攻击者可以利用MCP服务器作为第三方API的中介，导致混淆的代理漏洞。通过使用被盗的授权码，他们可以在未经用户同意的情况下获得访问令牌。
使用静态客户端ID的MCP代理服务器在转发到第三方授权服务器之前，必须获得每个动态注册客户端的用户同意（这可能需要额外的同意）。​

访问令牌权限限制

如果MCP服务器接受为其他资源颁发的令牌，攻击者可以获得未经授权的访问或以其他方式危害MCP服务器。
此漏洞有两个关键方面：

• 受众验证失败。当MCP服务器没有验证令牌是否专门针对它时（例如，通过RFC9068中提到的受众声明），它可能会接受最初为其他服务颁发的令牌。这打破了OAuth的基本安全边界，允许攻击者在不同的服务中重复使用合法令牌。
• 令牌传递。如果MCP服务器不仅接受受众不正确的令牌，而且还将这些未修改的令牌转发给下游服务，则可能会导致“代理混淆”问题，即下游API可能会错误地信任令牌，就好像令牌来自MCP服务器一样，或者认为令牌是由上游API验证的。有关更多详细信息，请参阅《安全最佳实践指南》的“令牌直通”部分。

MCP服务器在处理请求之前必须验证访问令牌，确保访问令牌是专门为MCP服务器颁发的，并采取一切必要措施确保没有数据返回给未经授权的各方。
MCP服务器必须遵循OAuth 2.1第5.2节中的指导方针来验证入站令牌。
MCP服务器必须只接受专门为自己设计的令牌，并且必须拒绝不包含在受众声明中的令牌，或者以其他方式验证它们是令牌的预期接收者。有关详细信息，请参阅安全最佳实践令牌传递部分。
如果MCP服务器向上游API发出请求，它可能会充当它们的OAuth客户端。在上游API使用的访问令牌是一个单独的令牌，由上游授权服务器发布。MCP服务器不得传递它从MCP客户端收到的令牌。
MCP客户端必须实现并使用RFC 8707-OAuth 2.0的资源指示符中定义的资源参数，以明确指定请求令牌的目标资源。这一要求与RFC 9728第7.4节中的建议一致。这确保了访问令牌绑定到其预期的资源，并且不会在不同的服务之间被滥用。