摘要：
本文旨在深入剖析火山引擎 Model Context Protocol (MCP) 开放生态下的 OAuth 授权安全挑战，并系统阐述火山引擎为此构建的多层次、纵深防御安全方案。面对由 OAuth 2.0 动态客户端注册带来的灵活性与潜在风险，我们设计了从“事前预防”到“事中限制”，再到“事后兜底”的完整安全闭环。该体系通过授权前二次确认、令牌身份与权限隔离、以及 API 级别精细化管控等关键举措，在确保 MCP 生态灵活开放的同时，最大限度地保障用户资产与数据安全，构建值得信赖的开发者生态。
上一期我们介绍了MCP全生命周期中的安全保障实践，没看过的小伙伴可以戳这里： 当AI智能体学会“欺骗”，我们如何自保？来自火山的MCP安全答卷
一. 背景：MCP OAuth 的开放性与安全挑战
MCP (Model Context Protocol) 协议致力于构建一个开放、繁荣的 AI 模型与应用生态。其核心理念是允许第三方开发者和服务提供商能够便捷地将其客户端应用（如本地 IDE 插件 Cursor、VS Code）或远程服务（如火山方舟等 SaaS 平台）无缝对接到 MCP 生态中，消费和提供模型能力。这种开放模式极大地激发了生态的创新活力，但也对平台的安全架构提出了前所未有的挑战。
为了支撑这种高度灵活的接入模式，服务端无法像传统应用那样预先静态注册所有客户端。因此，MCP 官方文档采用了 OAuth 2.0 动态客户端注册协议（RFC 7591）。该协议允许客户端在 OAuth 授权流程中，通过向一个标准的 /register 端点发起请求，动态地获取合法的客户端凭证（client_id, client_secret）。这免除了开发者在授权服务提供商处进行繁琐的手动预注册流程，极大地降低了接入成本。
注：上图圈出部分即为动态客户端注册流程。
然而，这种“先上车，后补票”的模式在赋予生态极致灵活性的同时，也从根本上改变了授权服务器对客户端的信任模型。传统的静态注册模式下，客户端被认为是可信的、经过审核的；而在动态注册模式下，任何应用都可以声明自己是合法的客户端，授权服务器必须将所有客户端都视为潜在的不可信实体。这正是 MCP OAuth 安全挑战的核心根源。Access Token 就像是一把“万能钥匙”，如果没有合理的安全管控，攻击者获取后即可冒充用户身份，造成数据泄露、服务接管等安全风险。
二. 核心风险深度剖析
基于动态客户端注册的开放特性，攻击者可以利用多种攻击向量来破坏授权流程，窃取用户凭证。我们识别出以下几个核心风险：
2.1 风险一：恶意客户端通过授权码拦截窃取用户令牌
这是最直接的攻击方式。由于任何应用都能动态注册为合法客户端，攻击者可以构建一个功能与正常应用类似的恶意 MCP 客户端，并通过各种渠道（如钓鱼邮件、非官方应用市场）诱导用户下载安装。
攻击 过程 详解：
- 攻击者诱导用户通过其恶意客户端发起 OAuth 授权请求。
- 用户的浏览器被重定向到火山引擎的授权页面，用户输入凭证并同意授权。
- 授权服务器生成一个授权码 (Authorization Code) ，并将其通过重定向发送到客户端预先注册的
redirect_uri。 - 由于
redirect_uri指向恶意客户端控制的地址，授权码被恶意客户端截获。 - 恶意客户端使用截获的授权码，连同自己的
client_id和client_secret，向授权服务器的/token端点请求交换访问令牌 (Access Token)。 - 授权服务器验证授权码和客户端凭证无误后，发放 Access Token 给恶意客户端。至此，用户令牌被成功窃取。
潜在影响：攻击者一旦获得用户的 Access Token，就可以在令牌的权限（scope）和有效期内，冒充用户身份执行所有允许的操作，例如：读取用户数据、调用付费服务、甚至修改用户配置，造成直接的经济损失和数据泄露。
2.2 风险二：恶意服务端利用“Confused Deputy”问题窃取令牌
即便 MCP 客户端本身是可信的，如果用户在客户端中添加了一个恶意的 MCP 服务端地址，风险同样存在。这在安全领域被称为 “Confused Deputy Problem ” 。
攻击 过程 详解：
- 用户在一个合法的、受信任的 MCP 客户端（如 Cursor）中，配置了一个由攻击者提供的恶意 MCP 服务端地址。
- 该恶意服务端指示用户的 MCP 客户端向一个合法的火山引擎授权服务发起认证请求。
- 用户在火山引擎完成认证授权后，授权服务器将 Access Token 安全地返回给合法的 MCP 客户端。
- 此时，合法的 MCP 客户端作为“Confused Deputy”，并不知道其正在交互的服务端是恶意的。它会按照正常业务流程，携带用户的 Access Token 去访问该恶意服务端。
- 恶意服务端接收到请求后，便成功窃取了附带在请求头或请求体中的用户 Access Token。
潜在影响：此风险的后果与风险一类似，但攻击路径更为隐蔽。它利用了用户对客户端的信任，以及客户端对用户配置的服务端的盲目信任，绕过了对客户端本身的攻击，直接在数据交互链路中窃取凭证。
2.3 风险三：令牌泄露与权限滥用
除了在授权流程中被主动窃取，Access Token 还可能因为其他原因被动泄露，例如：
-
客户端存储不当：客户端将令牌以明文形式存储在本地文件、数据库或浏览器 Local Storage 中，一旦设备被入侵，令牌极易泄露。
-
日志或传输泄露：在调试过程中，令牌被打印到日志中，或通过未加密的 HTTP 通道传输。
-
权限范围过大：客户端申请了远超其业务所需的权限（
scope），一旦令牌泄露，其造成的危害会被不成比例地放大。例如，一个只需要读取 ECS 列表的 MCP Server，却申请了读写用户 IAM 的权限。
三. 如何缓解风险
基于 MCP 生态的开放特性，很难有一个中心化的服务商，能给所有的 MCP 客户端和服务端进行安全确认和准出，来解决掉“恶意客户端”和“恶意服务端”的问题。所以我们认为上述风险无法被彻底根除，而应通过一套完善的机制进行有效缓解。
我们认为缓解风险主要基于以下两个方向：
- 充分告知，主动防御：在授权跳转前，清晰地向用户展示跳转目标及授予权限，并要求二次确认，最大限度降低用户受骗风险。
- 限制影响，降低损失：即使用户不幸受骗，也能将 Access Token 泄露后的潜在危害降至最低。
四. 火山引擎的纵深防御与修复方案
为应对上述来自客户端与服务端的双重风险，参考以上的修复方向，我们设计了如下三层缓解机制：
4.1 授权前二次确认，有效防范钓鱼攻击
在 OAuth 认证流程结束、即将跳转回客户端前，火山引擎的授权页面会作为一个关键的“安全闸门”，向用户清晰展示以下信息，并要求用户主动进行二次确认：
- 授予客户端的权限详情：明确告知客户端将获取哪些权限，例如“获取您的用户身份信息 (
identity)”、“访问 XX MCP 服务”等。权限描述必须通俗易懂。 - 待跳转的外部链接：完整显示将要重定向的目标
redirect_uri，让用户对跳转行为有明确预期。
这一“主动防御”措施确保用户在充分知情的情况下完成授权，有效打断了无感知的钓鱼攻击流程。
4.2 令牌身份隔离 ，限制风险半径
我们深知仅有用户提示不足以构建坚实的安全防线。为此，我们采取了关键的“令牌身份隔离”措施，其核心价值在于缩小攻击面和风险半径。
火山引擎确保通过 MCP OAuth 流程获取的 Access Token，与火山引擎主站的登录态（Session）严格隔离。这意味着，即便此 Access Token 失窃，攻击者也无法利用它获取用户在火山引擎官网的完整登录权限，进而染指用户在主站的核心资产。
通过这种方式，我们将令牌的权限严格限制在合法的 MCP 服务端功能范围内，有效防止了“账户完全托管”级别的重大风险。
4.3 API 级别权限管控，贯彻最小权限原则
为应对 MCP 服务端自身被攻陷或存在漏洞的极端情况，我们设计了第三层兜底措施——严格的权限边界管控。
我们要求每个 MCP 服务端必须以 API 级别，精细化地注册其运行所需的全部权限，所有权限的申请都必须经过火山引擎安全工程师的严格审核，确保服务不会获取任何超出其业务范畴的权限。
权限 设计原则：
- 拒绝宽泛权限：禁止如
*,Describe*等模糊不清的权限。 - 遵循功能边界：权限应与具体功能对应。
- 最小权限原则：只获取必要的权限。
这一举措确保了即使在 MCP 服务自身出现安全漏洞的情况下，攻击者能够通过窃取的令牌所能执行的操作，也被严格限制在预先审核过的最小范围内，从而最大限度地保护了用户的数据安全。
五. 总结
面对 MCP 开放生态带来的 OAuth 安全挑战，火山引擎并未选择以牺牲开放性为代价，而是构建了一套“事前预防、事中限制、事后兜底”的多层次纵深防御体系。
- 授权前二次确认作为第一道防线，主动防范钓鱼攻击。
- 令牌身份隔离作为核心举措，极大限制了风险半径，防止危害横向扩散。
- API 级别权限管控遵循最小权限原则，为潜在的未知风险提供了最终的安全保障。
这套组合方案协同作用，在保障 MCP 生态健康、开放发展的同时，也体现了火山引擎对用户资产安全的高度重视和对平台安全治理的坚定承诺。
六. 关于火山引擎云平台安全保障团队
团队负责火山引擎和 BytePlus 所有 ToB 业务与云平台底座的安全保障，包括安全架构、SDLC、漏洞运营、安全事件响应、安全合规等，确保火山引擎和 BytePlus 平台安全，助力云业务成功。
本文作者来自火山引擎云平台安全保障团队罗泽宇，杨月，曲乐炜。
