1.授权协议概述 #
MCP（Model Context Protocol）在传输层提供授权能力，使MCP客户端能够代表资源所有者向受限制的MCP服务器发起请求。本规范定义了基于HTTP传输的授权流程。
2. 介绍 #
2.1 目的与范围 #
Model Context Protocol在传输层提供授权能力，使MCP客户端能够代表资源所有者向受限制的MCP服务器发起请求。本规范定义了基于HTTP传输的授权流程。
2.2 协议要求 #
授权是可选对于MCP实现。当支持时：
- 使用基于HTTP传输的实现应该符合此规范。
- 使用STDIO传输的实现不应该遵循此规范，改为从环境中检索凭据。
- 使用替代传输方式的实现必须遵循其协议既定的安全最佳实践。
2.3 标准合规性 #
该授权机制基于以下列出的既定规范，但仅实现了其功能的一个精选子集，以确保安全性和互操作性，同时保持简洁性。
3. 授权流程 #
3.1 角色 #
受保护的MCP服务器充当OAuth 2.1 资源服务器，能够接收并使用访问Access Token响应受保护资源的请求。
MCP客户端充当OAuth 2.1 客户端，代表资源所有者发出受保护资源的请求。
授权服务器负责与用户交互（如有必要）并发放用于MCP服务器的访问Access Token。授权服务器的具体实现细节不在本规范讨论范围内，它可能与资源服务器托管在一起，也可能是一个独立实体。授权服务器发现部分指定了MCP服务器如何向客户端指示其对应授权服务器的位置。
3.2 概述 #
- 授权服务器必须实现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授权服务器元数据。
3.3 授权服务器发现 #
本节描述了MCP服务器向MCP客户端通告其关联授权服务器的机制，以及MCP客户端发现授权服务器端点和支持功能的流程。
3.3.1 授权服务器位置 #
MCP服务器必须实现OAuth 2.0受保护资源的元数据（RFC9728）用于指示授权服务器位置的规范。MCP服务器返回的受保护资源元数据文档必须包含authorization_servers至少包含一个授权服务器的字段。
具体使用authorization_servers这超出了本规范的范畴；实现者应参考OAuth 2.0受保护资源元数据（RFC9728）获取实现细节的指导。
实现者应注意，Protected Resource Metadata文档可以定义多个授权服务器。选择使用哪个授权服务器的责任在于MCP客户端，需遵循其中指定的指导原则。RFC9728 第7.6节"授权服务器"。
MCP服务器必须使用HTTP头部WWW-Authenticate当返回一个401 未经授权用于指示资源服务器元数据URL的位置，如所述RFC9728 第5.1节"WWW-Authenticate响应"。
MCP客户端必须能够解析WWW-Authenticate头部信息并作出相应处理HTTP 401 Unauthorized来自MCP服务器的响应。
3.3.2 服务器元数据发现 #
MCP客户端必须遵循OAuth 2.0授权服务器元数据规范（RFC8414）获取与授权服务器交互所需信息的规范。
3.3.3 序列图 #
以下图表概述了一个示例流程：
3.4 动态客户端注册 #
MCP客户端与授权服务器应该支持OAuth 2.0动态客户端注册协议（RFC7591标准）允许MCP客户端无需用户交互即可获取OAuth客户端ID。这为客户端提供了一种标准化的方式来自动向新授权服务器注册，这对MCP至关重要，因为：
- 客户端可能无法预先知道所有可能的MCP服务器及其授权服务器。
- 手动注册会给用户带来不便。
- 它能够无缝连接到新的MCP服务器及其授权服务器。
- 授权服务器可以实现自己的注册策略。
任何授权服务器不要支持动态客户端注册需要提供获取客户端ID（以及适用的客户端凭据）的替代方式。对于其中一台授权服务器，MCP客户端将必须选择以下方式之一：
- 为MCP客户端硬编码一个特定的client ID（以及适用的客户端凭证），以便在与该授权服务器交互时使用，或者
- 向用户提供一个UI界面，让他们在自行注册OAuth客户端（例如通过服务器托管的配置界面）后，能够输入这些详细信息。
3.5 授权流程步骤 #
完整的授权流程如下：
3.5.1 资源参数实现 #
MCP客户端必须实现 OAuth 2.0 中定义的 Resource Indicators（RFC 8707）明确指定请求Access Token所针对的目标资源。resource参数：
- 必须将被包含在授权请求和Access Token请求中。
- 必须识别客户端打算使用该Access Token的MCP服务器。
- 必须使用MCP服务器定义的规范URI（RFC 8707 第2节）。
3.5.1.1 Canonical Server URI #
出于本规范的目的，MCP服务器的规范URI被定义为资源标识符，具体说明于RFC 8707 第2节并且与...保持一致resource参数在RFC 9728。
MCP客户端应该提供他们打算访问的MCP服务器最具体的URI，遵循指南中的说明RFC 8707虽然规范形式使用小写的scheme和host组件，但实现中应该接受大写的scheme和host组件，以增强健壮性和互操作性。
有效的规范URI示例：
https://mcp.example.com/mcphttps://mcp.example.comhttps://mcp.example.com:8443https://mcp.example.com/server/mcp（当路径组件是识别单个MCP服务器所必需时）
无效规范URI的示例：
mcp.example.com(缺少方案)https://mcp.example.com#fragment（包含片段）
注意： 尽管两者
https://mcp.example.com/（带尾部斜杠）和https://mcp.example.com(不带尾部斜杠)在技术上根据规范是有效的绝对URI（RFC 3986）实现应该为了更好的互操作性，应始终使用不带尾部斜杠的形式，除非该尾部斜杠对特定资源具有语义上的重要性。
例如，在访问MCP服务器时https://mcp.example.com授权请求将包含：
&resource=https%3A%2F%2Fmcp.example.comMCP客户端必须无论授权服务器是否支持，都要发送此参数。
4. 访问Access Token使用 #
4.1 Access Token要求 #
向MCP服务器发起请求时的访问Access Token处理必须符合定义的要求（OAuth 2.1 第5节"资源请求"）具体来说：
- MCP客户端必须使用Authorization请求头字段定义在（OAuth 2.1 第5.1.1节）：
Authorization: Bearer <access-token>请注意授权必须包含在从客户端到服务器的每个HTTP请求中，即使它们属于同一逻辑会话。
- 访问Access Token必须不包含在URI查询字符串中
示例请求：
GET /mcp HTTP/1.1
Host: mcp.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...4.2 Access Token处理 #
MCP服务器作为OAuth 2.1资源服务器运行时必须按照所述方法验证访问Access Token（OAuth 2.1 第5.2节）MCP服务器必须验证访问Access Token是否专门作为目标受众颁发给他们，根据（RFC 8707 第2节）如果验证失败，服务器必须根据情况回应（OAuth 2.1 第5.3节）错误处理要求。无效或过期的Access Token必须收到一个HTTP 401响应。
MCP客户端不得向MCP服务器发送非其授权服务器发行的Token。
授权服务器必须仅接受可用于其自身资源的有效token。
MCP服务器不得不接受或中转任何其他Token。
5. 错误处理 #
服务器必须返回适当的HTTP状态码以处理授权错误
| 状态码 | 描述 | 用法 |
|---|---|---|
| 401 | 未经授权 | 需要授权或Access Token无效 |
| 403 | 禁止 | 无效的作用域或权限不足 |
| 400 | 错误请求 | 授权请求格式错误 |
6. 安全注意事项 #
实现必须遵循OAuth 2.1规范中列出的安全最佳实践（OAuth 2.1 第7节 "安全注意事项"）。
6.1 Access Token受众绑定与验证 #
RFC 8707资源指示器通过将Access Token绑定至其预期受众，提供了关键的安全优势。当授权服务器支持该功能时为了促进当前及未来的采用：
- MCP客户端必须包含
resource授权和Access Token请求中指定的参数（资源参数实现部分） - MCP服务器必须验证所出示的Access Token是否专为其使用而签发
该安全最佳实践文档概述了为何Token受众验证至关重要，以及为何明确禁止Token透传。
6.2 Access Token窃取 #
攻击者若获取了客户端存储的Access Token，或是服务器端缓存或日志中的Access Token，就能以对资源服务器看似合法的请求访问受保护资源。
客户端与服务器必须实现安全的Access Token存储并遵循OAuth最佳实践，如所述（OAuth 2.1，第7.1节）。
授权服务器应该发放短期有效的访问Access Token以减少Access Token泄露的影响。对于公共客户端，授权服务器必须按照所述方法轮换刷新Access Token（OAuth 2.1 第4.3.1节"Access Token端点扩展"）。
6.3 通信安全 #
实现必须跟随（OAuth 2.1 第1.5节"通信安全"）。
具体而言：
- 所有授权服务器端点必须通过HTTPS提供服务。
- 所有重定向URI必须可能是
localhost或使用HTTPS。
6.4 授权码保护 #
已获取授权响应中包含的授权代码的攻击者可能会尝试兑换该授权代码以获取访问Access Token，或以其他方式利用该授权代码。（进一步描述见OAuth 2.1 第7.5节）
为了缓解这一问题，MCP客户端必须根据PKCE规范实现（OAuth 2.1 第7.5.2节）PKCE通过要求客户端创建一对秘密的验证器-质询对，有助于防止授权码被截获和注入攻击，确保只有原始请求者才能用授权码换取Access Token。
6.5 开放式重定向 #
攻击者可能伪造恶意重定向URI，将用户导向钓鱼网站。
MCP 客户端必须已在授权服务器注册重定向URI。
授权服务器必须验证重定向URI是否与预先注册的值完全匹配，以防止重定向攻击。
MCP客户端应该在授权码流程中使用并验证state参数，并丢弃任何不包含或与原始state不匹配的结果。
授权服务器必须采取措施防止将用户代理重定向至不可信的URI，遵循以下建议：（OAuth 2.1 章节 7.12.2）
授权服务器应该仅在用户代理信任重定向URI时自动执行重定向。若该URI不受信任，授权服务器可能通知用户并依赖用户做出正确决定。
6.6 混淆代理问题 #
攻击者可以利用充当第三方API中介的MCP服务器，从而混淆代理漏洞通过使用窃取的授权码，他们可以在未经用户同意的情况下获取访问Access Token。
使用静态客户端ID的MCP代理服务器必须在转发至第三方授权服务器（可能需要额外同意）之前，需获取用户对每个动态注册客户端的明确同意。
6.7 访问Access Token权限限制 #
攻击者可能获取未经授权的访问权限或以其他方式危害MCP服务器，如果该服务器接受为其他资源颁发的Access Token。
此漏洞具有两个关键维度：
受众验证失败。 当MCP服务器未验证Access Token是否专门为其生成时（例如，通过audience声明，如前所述），（RFC9068），它可能接受原本为其他服务颁发的Access Token。这破坏了OAuth的基本安全边界，使得攻击者能够在非预期服务间重复使用合法Access Token。
Access Token透传。 如果MCP服务器不仅接受受众不正确的Access Token，还将这些未经修改的Access Token转发给下游服务，则可能引发"混淆代理"问题，下游API可能错误地信任该Access Token，仿佛它来自MCP服务器，或假定该Access Token已被上游API验证。参见Token 透传部分请参阅《安全最佳实践指南》以获取更多详情。
MCP服务器必须在处理请求前验证访问Access Token，确保该访问Access Token是专门为MCP服务器签发的，并采取一切必要措施防止数据泄露给未授权方。
一个MCP服务器必须遵循指南中的要求（OAuth 2.1 - 第5.2节）验证入站Access Token。
MCP服务器必须仅接受专门为自身设计的token必须拒绝那些未在受众声明中包含它们或未以其他方式验证它们是Access Token预期接收者的Access Token。参见安全最佳实践中的Token透传部分详情请见。
如果MCP服务器向上游API发起请求，它可能作为OAuth客户端与它们交互。上游API使用的访问Access Token是由上游授权服务器单独颁发的独立Access Token。MCP服务器必须不传递它从MCP客户端接收到的token。
MCP客户端必须实现并使用resource参数定义于（RFC 8707 - OAuth 2.0资源指示符）明确指定Access Token请求所针对的目标资源。这一要求符合（RFC 9728 第7.4节）这确保了访问Access Token与其目标资源绑定，无法在不同服务间被滥用。