資料來源：火山引擎-開發者社區

本文旨在深入剖析火山引擎 Model Context Protocol (MCP) 開放生態下的 OAuth 授權安全挑戰，并系統闡述火山引擎為此構建的多層次、縱深防御安全方案。面對由 OAuth 2.0 動態客戶端注冊帶來的靈活性與潛在風險，我們設計了從“事前防御”到“事中限制”，再到“事后兜底”的完整安全閉環。該體系通過授權前二次確認、令牌身份與權限隔離以及 API 級別精細化管控等關鍵舉措，在確保 MCP 生態靈活開放的同時，最大限度地保障用戶資產與數據安全，構建值得信賴的開發者生態。

上一期我們介紹了 MCP 全生命周期中的安全保障實踐，點擊可查看：火山引擎 MCP 安全架構與實踐

本文旨在深入剖析火山引擎 Model Context Protocol (MCP) 開放生態下的 OAuth 授權安全挑戰，并系統闡述火山引擎為此構建的多層次、縱深防御安全方案。面對由 OAuth 2.0動態客戶端注冊帶來的靈活性與潛在風險，我們設計了從“事前預防”到“事中限制”，再到“事后兜底”的完整安全閉環。該體系通過授權前二次確認、令牌身份與權限隔離、以及 API 級別精細化管控等關鍵舉措，在確保 MCP 生態靈活開放的同時，最大限度地保障用戶資產與數據安全，構建值得信賴的開發者生態。

上一期我們介紹了 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 就像是一把“萬能鑰匙”，如果沒有合理的安全管控，攻擊者獲取后即可冒充用戶身份，造成數據泄露、服務接管等安全風險。
核心風險深度剖析
基于動態客戶端注冊的開放特性，攻擊者可以利用多種攻擊向量來破壞授權流程，竊取用戶憑證。我們識別出以下幾個核心風險：
風險一：惡意客戶端通過授權碼攔截竊取用戶令牌
這是最直接的攻擊方式。由于任何應用都能動態注冊為合法客戶端，攻擊者可以構建一個功能與正常應用類似的惡意 MCP 客戶端，并通過各種渠道（如釣魚郵件、非官方應用市場）誘導用戶下載安裝。
攻擊過程詳解：
1.攻擊者誘導用戶通過其惡意客戶端發起 OAuth 授權請求。
2.用戶的瀏覽器被重定向到火山引擎的授權頁面，用戶輸入憑證并同意授權。
3.授權服務器生成一個授權碼 (Authorization Code)，并將其通過重定向發送到客戶端預先注冊的 redirect_uri。
4.由于 redirect_uri 指向惡意客戶端控制的地址，授權碼被惡意客戶端截獲。
5.惡意客戶端使用截獲的授權碼，連同自己的 client_id 和 client_secret，向授權服務器的 /token 端點請求交換訪問令牌 (Access Token)。
6.授權服務器驗證授權碼和客戶端憑證無誤后，發放 Access Token 給惡意客戶端。至此，用戶令牌被成功竊取。
潛在影響：攻擊者一旦獲得用戶的 Access Token，就可以在令牌的權限（scope）和有效期內，冒充用戶身份執行所有允許的操作，例如：讀取用戶數據、調用付費服務、甚至修改用戶配置，造成直接的經濟損失和數據泄露。

風險二：惡意服務端利用“Confused Deputy”問題竊取令牌
即便 MCP 客戶端本身是可信的，如果用戶在客戶端中添加了一個惡意的 MCP 服務端地址，風險同樣存在。這在安全領域被稱為“Confused Deputy Problem”。
攻擊過程詳解：
1.用戶在一個合法的、受信任的 MCP 客戶端（如 Cursor）中，配置了一個由攻擊者提供的惡意 MCP 服務端地址。
2.該惡意服務端指示用戶的 MCP 客戶端向一個合法的火山引擎授權服務發起認證請求。
3.用戶在火山引擎完成認證授權后，授權服務器將 Access Token 安全地返回給合法的 MCP 客戶端。
4.此時，合法的 MCP 客戶端作為“Confused Deputy”，并不知道其正在交互的服務端是惡意的。它會按照正常業務流程，攜帶用戶的 Access Token 去訪問該惡意服務端。
5.惡意服務端接收到請求后，便成功竊取了附帶在請求頭或請求體中的用戶 Access Token。
潛在影響：此風險的后果與風險一類似，但攻擊路徑更為隱蔽。它利用了用戶對客戶端的信任，以及客戶端對用戶配置的服務端的盲目信任，繞過了對客戶端本身的攻擊，直接在數據交互鏈路中竊取憑證。

風險三：令牌泄露與權限濫用
除了在授權流程中被主動竊取，Access Token 還可能因為其他原因被動泄露，例如：

• 客戶端存儲不當：客戶端將令牌以明文形式存儲在本地文件、數據庫或瀏覽器 Local Storage 中，一旦設備被入侵，令牌極易泄露。
• 日志或傳輸泄露：在調試過程中，令牌被打印到日志中，或通過未加密的 HTTP 通道傳輸。
• 權限范圍過大：客戶端申請了遠超其業務所需的權限（scope），一旦令牌泄露，其造成的危害會被不成比例地放大。例如，一個只需要讀取 ECS 列表的 MCP Server，卻申請了讀寫用戶 IAM 的權限。

如何緩解風險
基于 MCP 生態的開放特性，很難有一個中心化的服務商，能給所有的 MCP 客戶端和服務端進行安全確認和準出，來解決掉“惡意客戶端”和“惡意服務端”的問題。所以我們認為上述風險無法被徹底根除，而應通過一套完善的機制進行有效緩解。
我們認為緩解風險主要基于以下兩個方向：
1.充分告知，主動防御：在授權跳轉前，清晰地向用戶展示跳轉目標及授予權限，并要求二次確認，最大限度降低用戶受騙風險。
2.限制影響，降低損失：即使用戶不幸受騙，也能將 Access Token 泄露后的潛在危害降至最低。

火山引擎的縱深防御與修復方案
為應對上述來自客戶端與服務端的雙重風險，參考以上的修復方向，我們設計了如下三層緩解機制：
授權前二次確認，有效防范釣魚攻擊
在 OAuth 認證流程結束、即將跳轉回客戶端前，火山引擎的授權頁面會作為一個關鍵的“安全閘門”，向用戶清晰展示以下信息，并要求用戶主動進行二次確認：
1.授予客戶端的權限詳情：明確告知客戶端將獲取哪些權限，例如“獲取您的用戶身份信息 (identity)”、“訪問 XX MCP 服務”等。權限描述必須通俗易懂。
2.待跳轉的外部鏈接：完整顯示將要重定向的目標 redirect_uri，讓用戶對跳轉行為有明確預期。

這一“主動防御”措施確保用戶在充分知情的情況下完成授權，有效打斷了無感知的釣魚攻擊流程。
令牌身份隔離 ，限制風險半徑
我們深知僅有用戶提示不足以構建堅實的安全防線。為此，我們采取了關鍵的“令牌身份隔離”措施，其核心價值在于縮小攻擊面和風險半徑。
火山引擎確保通過 MCP OAuth 流程獲取的 Access Token，與火山引擎主站的登錄態（Session）嚴格隔離。這意味著，即便此 Access Token 失竊，攻擊者也無法利用它獲取用戶在火山引擎官網的完整登錄權限，進而染指用戶在主站的核心資產。

通過這種方式，我們將令牌的權限嚴格限制在合法的 MCP 服務端功能范圍內，有效防止了“賬戶完全托管”級別的重大風險。
API 級別權限管控，貫徹最小權限原則
為應對 MCP 服務端自身被攻陷或存在漏洞的極端情況，我們設計了第三層兜底措施——嚴格的權限邊界管控。
我們要求每個 MCP 服務端必須以 API 級別，精細化地注冊其運行所需的全部權限，所有權限的申請都必須經過火山引擎安全工程師的嚴格審核，確保服務不會獲取任何超出其業務范疇的權限。

權限設計原則：

• 拒絕寬泛權限：禁止如 * , Describe* 等模糊不清的權限。
• 遵循功能邊界：權限應與具體功能對應。
• 最小權限原則：只獲取必要的權限。

這一舉措確保了即使在 MCP 服務自身出現安全漏洞的情況下，攻擊者能夠通過竊取的令牌所能執行的操作，也被嚴格限制在預先審核過的最小范圍內，從而最大限度地保護了用戶的數據安全。
總結
面對 MCP 開放生態帶來的 OAuth 安全挑戰，火山引擎并未選擇以犧牲開放性為代價，而是構建了一套“事前預防、事中限制、事后兜底”的多層次縱深防御體系。

• 授權前二次確認作為第一道防線，主動防范釣魚攻擊。
• 令牌身份隔離作為核心舉措，極大限制了風險半徑，防止危害橫向擴散。
• API 級別權限管控遵循最小權限原則，為潛在的未知風險提供了最終的安全保障。

這套組合方案協同作用，在保障 MCP 生態健康、開放發展的同時，也體現了火山引擎對用戶資產安全的高度重視和對平臺安全治理的堅定承諾。
關于火山引擎云平臺安全保障團隊
團隊負責火山引擎和 BytePlus 所有 ToB 業務與云平臺底座的安全保障，包括安全架構、SDLC、漏洞運營、安全事件響應、安全合規等，確保火山引擎和 BytePlus 平臺安全，助力云業務成功。
本文作者來自火山引擎云平臺安全保障團隊羅澤宇，楊月，曲樂煒。