文章总结： 本文分析了MCP协议在企业部署中的身份验证与授权安全现状，揭示了工具投毒、命令注入及SSO中介漏洞等攻击面。指出当前OAuth2实现碎片化严重，且企业托管授权草案存在令牌撤销缺失、绕过用户同意等隐患。建议企业采用mTLS等强信任锚点，严格验证授权链，分离用户委派与执行上下文，避免盲目照搬传统SSO带来的风险。 综合评分： 92 文章分类： AI安全,漏洞分析,应用安全,安全建设

MCP 身份验证乱局：从安全噩梦到企业如何自救

幻泉之洲

2026年3月12日 15:38 北京

搞AI应用的公司，如果你们在用MCP（模型上下文协议）连接工具和数据，这篇你得看看。它从安全分析师视角，梳理了MCP认证授权的现状、各种攻击手法，以及正在讨论的”企业托管授权”草案背后的严重隐患。作者认为现在这套东西问题太多，搞不好就会爆出大雷。

这篇文章想聊聊MCP服务器在企业远程部署场景下的身份验证（Authentication）和授权（Authorization）现状，说白了就是安全情况到底怎么样。

在深入讨论之前，我们先得理一理最常见的攻击路径。搞明白这些威胁，才能看清楚接下来要面对的安全挑战具体是啥。如果你是行内人，对这部分已经很熟了，可以直接跳到“企业级认证和授权：还在路上”那部分。

现在关于模型上下文协议（MCP）的介绍已经铺天盖地了，我就不在这赘述了。

为错过这波讨论的朋友简单总结一下：MCP是用来连接AI模型与数据、工具、提示词的协议。它用JSON-RPC消息通信，连接本身是有状态的，客户端和服务器之间要协商能力。

参考资料：MCP规范[2]与MCP架构[3]

MCP攻击手法一览

实践中，我们已经看到好几类MCP相关的漏洞。虽然不一定能涵盖你听到的所有漏洞（因为情况天天在变），但OWASP的MCP十大安全风险[4]是个不错的起点。

下面是我们到目前为止遇到的最相关的漏洞，按攻击者的角色来划分：

恶意MCP服务器

恶意的MCP服务器可以有意地利用客户端，手段包括：

• 工具投毒（Tool Poisoning）：服务器提供恶意的工具定义，或在用户批准后修改它们。这个攻击有几种变体：

• Rug Pulls：服务器在初始调用时展示的是良性的能力，但在执行过程中或后续的MCP消息中（比如工具列表更新时）切换成恶意的。

• 工具遮蔽（Tool Shadowing）：恶意服务器注入工具描述，以修改智能体对一个受信任工具的行为。

• 模式投毒（Schema Poisoning）：破坏接口定义以误导模型。模式被MCP客户端用来验证工具的输入输出，也让模型知道调用它们需要什么。

• 通过工具响应进行提示注入：服务器在向正常操作的MCP响应中嵌入恶意指令，然后由客户端的LLM执行。

• 通过资源泄露数据：恶意服务器暴露会泄露敏感客户端信息等内容的资源。

需要指出，上述列出的攻击无论是本地还是远程的MCP服务器都可能利用。当然，能达到的破坏效果差异巨大。

恶意MCP客户端

恶意的MCP客户端可以有意地利用服务器，包括：

• 命令注入：精心构造的MCP消息输入被发送到存在漏洞的MCP服务器，这些服务器没有正确清理输入，导致任意命令执行。
• 上下文注入与过度共享：服务器没有正确隔离上下文，导致从其他用户/会话中泄露敏感信息。
• 提示注入：MCP服务器可能从客户端接收恶意提示词，这会修改其行为以执行请求的任务。

其他恶意行为者

除了传统的客户端-服务器因素，MCP生态系统还可能通过以下方式被破坏：

• MCP代理/网关：用于路由和授权MCP的中介系统。这些东西可以篡改传递的MCP消息，或者本身就存在策略绕过漏洞。（看看GitHub上MCP网关的数量，你可能会吓一跳：https://github.com/e2b-dev/awesome-mcp-gateways?tab=readme-ov-file）
• 单点登录（SSO）中介：使用OAuth 2.0/2.1进行授权的MCP服务器依赖于发现端点（.well-known/oauth-authorization-server）和动态客户端注册。攻击者可能通过这些中介注入伪造的元数据、操纵重定向URI，或攻破注册端点来获取未经授权的客户端凭据。

噩梦之源：新玩家，老问题变本加厉

由于其固有的复杂性，保护SSO对整个行业来说仍然是一个开放的挑战。过去几年凸显了这一现实，影响OAuth2、OIDC、SAML和SCIM实现的严重漏洞源源不断。

但发展不会停止，MCP中的身份验证和授权成了新的、不可避免的噩梦。作为一个相对较新的协议，客户端和服务器应该如何建立信任的标准仍在发展中，这导致了一个碎片化的生态系统。

关于身份验证/授权的规范在不断变化和扩展，这对新生协议来说很常见。这种不稳定性意味着，今天“安全且合规”的实现，明天可能就被弃用或变得不够安全。

MCP的SSO实现中已经出现了多个严重问题，其中很多是常见OAuth2/OIDC漏洞的衍生，但也有全新的。

我们看到基于浏览器的客户端或open() URL处理程序被利用来启动任意进程或重定向到恶意服务器，这表明MCP客户端实现的脆弱性，通常与自动操作执行器有关。

然后是对新的元数据发现和经典的元数据端点的攻击：

• 被注入恶意URI方案的保护资源元数据（PRM）文档。
• 被操纵以重定向流量的OIDC发现端点。

围绕这些场景值得注意的漏洞有：CVE-2025-6514，“From MCP to Shell”，CVE-2025-4144，CVE-2025-4143，CVE-2025-58062等。

此外，许多实现（如IDE扩展）想当然地认为localhost是安全的，在没有身份验证的情况下启动WebSocket服务器，允许任何本地进程（或通过DNS重绑定的恶意网站）进行连接。

虽然跟上最新消息相当复杂、耗时，而且并非总是可能，但我们还是尝试总结了影响当前通过OAuth2和动态客户端注册进行MCP身份验证的潜在注入点。

一张让人头皮发麻的序列图

下面的庞然序列图精准地体现了本文的标题，提醒我们攻击面有多广，注入点有多少个。有人说“每一步都是一个注入点”，这个说法并不夸张。我们的目标是完整展示授权流程的全貌，突出其许多分支、变体，以及那些微妙但影响巨大的漏洞机会。

高分辨率PDF文件可以在这里下载（PDF下载链接原文未提供）。

虽然提示注入需要不同的应对方法，但大多数注入点和影响严重的后果（如LFI、RCE等）都可以通过严格应用输入清理和验证来预防。尽管如此，这个庞大的流程图还是凸显了，考虑到整个流程的长度和参与者的多样性，要做到这一点有多么复杂。

企业级认证和授权：还在路上

在OAuth规范里，用户授权时需要确认许可范围。在身份提供商（IdP）颁发任何令牌之前，用户必须看到并批准每个第三方工具等的确切范围。

目前，还没有统一的方法在整个企业中全面管理MCP安全。虽然单个MCP工具在身份验证上很吃力，经常只是依赖密钥令牌，但企业级的身份验证/授权完全是另一个层面的挑战。

实际上，在企业托管的授权中，范围许可是与授权时间解耦的。举个例子，一个具有企业授权的MCP客户端可以代表用户访问Slack和GitHub，但用户从未在同意屏幕上明确同意过github:read或slack:write。是本地智能体决定了任务和所需范围，而企业策略执行者基于该MCP客户端的身份，代表用户决定允许这样做。

沿着这条路，有中介工具正试图提供部分解决方案，比如MCP代理/网关。它们非常有用，可以将MCP服务器聚合在同一个集中管理的认证和授权层下，但它们仍然没有解决动态范围和即插即用第三方工具/应用带来的新问题。

另一方面，社区正围绕“模型上下文协议的原生企业托管授权扩展”进行积极讨论。在研究这个问题过程中，我们有机会深入研究当前一个扩展草案，它依赖于身份断言JWT授权许可。鉴于我们客户在现实安全工程中遇到的挑战，我们决定更进一步，对这个草案提供反馈。强烈建议阅读这个扩展草案[5]和Doyensec提出的更新了安全考量的拉取请求[6]。

JAG的问题所在（身份断言JWT授权许可）

以下总结了JAG方案以及我们的思考。想深入了解所有方面的读者，我们建议先阅读完整草案[5]再继续。

这个规范的核心是围绕利用现有的企业身份提供商（如Okta或Azure AD）展开的。流程的关键点在于：

当前的规范引入了几个突出的挑战：

1. 访问失效问题

   ：流程会颁发三层令牌，而草案没有明确描述如何撤销对MCP客户端的访问权限或已颁发的令牌。

2. 未经用户同意的LLM范围滥用

   ：在JAG中，IdP颁发的身份令牌不包含范围。它只说明用户身份以便MCP客户端进行“身份冒充”。当MCP客户端为高风险范围（如github:write、slack:write）请求JAG时，不会触发任何同意弹窗。企业策略替被“冒充”的用户做决定。这在MCP领域是不适用的，任务的确定性不强，绕过同意要求会让LLM自主请求企业策略允许的任何范围，去掉了高危行动中的人为确认环节。

3. IdP如何创建、分发和验证客户端

   ：JAG草案没有声明IdP应如何颁发/分发客户端凭据，也没有明确IdP确保audience与resource相关联的重要性。这可能导致“范围命名空间冲突”和“资源标识符注入”问题。

4. ID-JAG重放担忧

   ：当一个ID-JAG可以铸造多个MCP服务器访问令牌，而这些令牌又能调用高影响力工具时，ID-JAG就成了破坏力的放大器。所以，强制对jti进行单次使用检查的决定应该属于规范的一部分。

怎么办？我们的看法

说实话，MCP在身份验证和授权这块，短时间内很难让人放心。因为它把SSO的复杂性和AI代理的不确定性搅和在了一起。

无论是审计人员还是开发者，现在最要紧的是在MCP涉及的每一个SSO步骤上都用最严格的标准去验证。那幅序列图就是个好工具——用它来推演整个授权链，找出信任边界，系统性地设计安全测试。

至于像JAG这样的企业托管授权草案，我们觉得风险不小。它依赖非确定性的智能体完全“冒充”用户，还去掉了每项操作的用户明确同意，这和MCP实际需要的安全要求是错位的。上下文约束不严的委派，在边界没有严格执行时，和特权提升没啥区别。

从我们的经验看，企业搞MCP部署，更靠谱的方向是强信任锚点和协议最小化。基于证书的授权和mTLS这类技术，如果能适配MCP的交互模型，能提供更清晰的安全特性。这些东西还需要配合：

• 对高风险或不可逆操作的明确保护。
• 统一集中的访问失效机制，用于应急响应。
• 严格的资源命名空间和确定性的范围映射。
• 清晰的用户委派与代理执行上下文的分离。

简单说，目标不应是把传统企业SSO那套复杂东西照搬进MCP，而是要减少隐式信任，约束委派语义，让授权决策变得可审计、可确定。

如果过去十年OAuth这些协议的漏洞教会了我们什么，那就是：没有强约束的复杂度，必然带来安全漏洞。MCP最好早点把这点记在心里。

参考资料

[1] https://goteleport.com/

[2] https://modelcontextprotocol.io/specification/2025-11-25

[3] https://modelcontextprotocol.io/specification/2025-11-25/architecture

[4] https://owasp.org/www-project-mcp-top-10/

[5] https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/draft/enterprise-managed-authorization.mdx

[6] https://github.com/modelcontextprotocol/ext-auth/pull/12

[7] https://blog.doyensec.com/2026/03/05/mcp-nightmare.html

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《MCP 身份验证乱局：从安全噩梦到企业如何自救》