譯者 | 核子可樂

審校 | 重樓

每種新協議都會帶來相應的復雜性，因此若無必要、勿增新協議。但模型上下文協議（MCP）無疑很有必要。

ChatGPT等AI工具已然掀起一波智能體應用浪潮，這些由大模型驅動的智能體擅長摘要、內容創作與圖像處理，但也存在一些根本性的局限：

• 無法訪問實時數據；
• 無法訪問私有數據；
• 無法使用工具。

作為一種通用協議，MCP能夠將智能體應用與現實世界的數據和工具連通，成功解決上述局限。但既然我們已經擁有一眾安全且高性能的API，那為什么還要引入新的協議？

答案并不復雜，雖然各類強大的API能夠接入智能體應用，但由于自身種類繁多、身份驗證機制又各不相同，意味著每次集成都存在大量定制化成分。開發者必須逐一閱讀文檔、構建流程才能接入API。

WSO2

這種靜態集成模型雖然成熟，但與智能體應用的動態特性并不匹配。MCP定義了清晰的客戶端-服務器角色、標準協議格式和生命周期，本質上成為大模型與外部系統間的通用連接器，因此不少從業者將MCP視為API領域的USB端口。

MCP工作原理

MCP定義了三大核心角色——主機、客戶端與服務器：

• 主機：管理客戶端生命周期，并具備強制安全保障的智能體應用。
• 客戶端：主機內的輕量級連接器，用于同MCP服務器建立一對一會話。
• 服務器：將MCP客戶端連接至本地或遠程數據源及工具的程序。

WSO2

各角色提供相應的功能。MCP服務器負責公開資源（如日歷事件等上下文數據）、提示詞（用于引導用戶輸入以改進大模型輸出的結構化模板）及工具（可執行函數）。MCP客戶端則接入MCP服務器以請求數據、操作工具并編排智能體。

MCP使用JSON-RPG（一種輕量級結構化協議）以處理請求及響應，并定義了兩種用于客戶端-服務器通信的標準傳輸機制：標準輸入輸出（STDIO）及可流式傳輸的HTTP。

保護本地MCP服務器

當MCP服務器運行在本地時，應使用STDIO傳輸。實際上，這意味著智能體應用將MCP服務器作為子進程啟動，并通過其標準輸入輸出流進行通信。由于此通信完全在本地系統內進行，因此本質上符合安全原理且MCP身份驗證規范無需借助額外安全措施。

WSO2

然而，當MCP服務器與后端API通信（大多通過互聯網）時，安全性要求成為首要任務、并超出了MCP身份驗證機制的范疇。盡管如此，這里仍不需要引入新機制：現有API安全實踐已經足以提供保障，常見方法包括：

• 長效令牌：有效期為數天或數月的API密鑰及令牌，通過帶外通道獲取并在MCP服務器中配置。
• 短效令牌：短效信息的有效期在一小時以內，無法手動設置。相反，MCP服務器必須在運行時動態請求并獲得用戶批準。典型例子包括OAuth2訪問令牌及JWT。

保護遠程MCP服務器

MCP客戶端通過向其端點URL發起請求，通過HTTP接入遠程MCP服務器。根據MCP身份驗證規范的規定，此端點必須受到OAuth 2.1保護，并要求客戶端提供有效訪問令牌。

WSO2

MCP身份驗證規范概述了令牌的獲取流程，旨在支持動態智能體集成。具體交互包括以下步驟：

WSO2

服務器元數據發現

在為MCP服務器提供URL配置參數之后，客戶端會移除所有路徑組件并附加/well-known/oauth-authorization-server路徑以構建服務器元數據端點。之后，客戶端從此端點處檢索JSON格式的服務器元數據文檔。端點及文檔都必須符合OAuth 2.0授權服務器元數據規范，且此元數據可幫助客戶端在后續步驟中發現以下所需信息：

• 注冊端點；
• 授權與令牌端點；
• 支持的授權類型與范圍。

從MCP服務器URL獲取服務器元數據端點的初衷，是讓客戶端使用單一配置參數進行操作。但這樣的設計會令授權與資源服務器角色緊密耦合，限制了現有OAuth 2.0基礎設施與專用身份解決方案的使用。為了解決這個問題，即將發布的MCP身份驗證規范將轉而采用OAuth 2.0受保護資源元數據規范。

客戶端注冊

根據從服務器元數據文檔中檢索到的信息，客戶端應用向客戶端注冊端點發送注冊請求。MCP身份驗證規范采用OAuth 2.0動態客戶端注冊（DCR）協議將客戶端注冊為OAuth 2.1客戶端。在DCR響應中，客戶端應用會收到一個client_id；對于機密客戶端，還會收到一個client_secret。這兩項參數將在下一步操作中用到。

盡管DCR得到廣泛采用，但人們對于開放注冊的評判并不一致，而且該規范本身允許使用OAuth 2.0保護注冊端點。同樣，為了支持單參數配置，MCP身份驗證規范建議采用開放注冊，未來如何發展仍有待觀察。

訪問令牌檢索

在此階段，客戶端已經做好了請求訪問令牌的所有準備。根據用例，客戶端將使用以下OAuth 2.1授權類型之一：

• 客戶端憑證：若客戶端應用直接訪問MCP服務器，則使用客戶端憑證授權，其中包含注冊期間獲得的client_id與client_secret，以及從服務器元數據中發現的令牌端點及范圍。
• 授權碼：若客戶端代表最終用戶訪問MCP服務器，則使用授權碼授權。此流程需要注冊時獲取的client_id與client_secret，以及從服務器元數據中獲取的授權端點、令牌端點及范圍。此外，根據OAuth 2.1的要求，客戶端必須使用碼交換證明密鑰（PKCE）以進一步增強安全性。

WSO2

若一切順利，客戶端應用將獲得有效訪問令牌，并可向MCP服務器URL發起連接請求，并通過Authorizatio nHTTP標頭傳遞令牌。之后，MCP服務器將驗證令牌，在確認有效后建立連接。

總體而言，整個安全流程與基于OAuth的典型API安全流程保持一致，唯一區別只有從MCP服務器URL獲取服務器元數據URL的初始步驟。

原文標題：Why MCP matters – and how to secure it，作者：Sagara Gunathunga