繁體中文（台灣）

mcp
mcp-auth
oauth

深入解析 MCP 授權規範（2025-03-26 版）

深度分析 MCP 授權規範，檢視 MCP 伺服器作為授權及資源伺服器的雙重角色、動態客戶端註冊機制，以及在實際應用中實施此協議的一些現實考量。

Yijun

Developer

4/8/2025

不要在使用者認證上浪費數週時間

使用 Logto 更快地發布安全應用程式。幾分鐘內整合使用者認證，專注於您的核心產品。

立即開始

MCP (模型上下文協議) 是一個開放標準，允許 AI 模型與外部工具和服務互動。業界已廣泛採用 MCP。由於 MCP 支援基於 HTTP 的傳輸方法，遠程 MCP 伺服器將在 MCP 生態系統中發揮越來越重要的作用。

與本地 MCP 伺服器不同，本地 MCP 伺服器允許每個用戶運行自己的伺服器實例，而遠程 MCP 伺服器要求所有用戶共享同一 MCP 伺服器服務。這引出了 MCP 授權規範要解決的核心問題：如何允許 MCP 伺服器代表用戶訪問用戶資源。

本文將深入分析 MCP 授權規範。這將幫助你了解 MCP 授權規範的設計原則以及一些實施 MCP 授權的方法。由於此規範仍在發展中，我將分享一些基於我個人在實施認證器過程中的經驗的想法，包括：

OAuth 2.1 作為授權框架的優勢和局限性
MCP 伺服器作為授權伺服器和資源伺服器的雙重角色的挑戰
實施完整授權伺服器的實際複雜性
委派第三方授權的合適場景分析
動態客戶端註冊的實際權衡
明確定義 MCP 伺服器資源邊界的重要性

MCP 授權規範概述

MCP 授權規範定義了 MCP 伺服器（遠程）和 MCP 客戶端之間的身份驗證過程。

我認為將此規範基於 OAuth 2.1 是非常合理的選擇。OAuth 作為授權協議框架，解決了如何允許用戶授權第三方應用訪問用戶資源的問題。如果你不熟悉 OAuth，你可以查看 AuthWiki-OAuth 獲取更多信息。

在 MCP 客戶端和 MCP 伺服器場景中，它關於“用戶授權 MCP 客戶端訪問 MCP 伺服器上的用戶資源”。“MCP 伺服器上的用戶資源”目前主要指 MCP 伺服器提供的工具或 MCP 伺服器後端服務提供的資源。

為了實施 OAuth 2.1 認證過程，協議要求 MCP 伺服器提供以下介面以與 MCP 客戶端協作完成 OAuth 2.1 認證過程：

/.well-known/oauth-authorization-server: OAuth 伺服器元數據
/authorize: 授權端點，用於授權請求
/token: 令牌端點，用於令牌交換和刷新
/register: 客戶端註冊端點，用於動態客戶端註冊

認證過程如下：

該規範還指定了 MCP 伺服器如何通過第三方授權伺服器支持委派授權。

規範中的示例流程如下（來自規範內容）：

在這種情況下，雖然 MCP 伺服器將授權委派給第三方授權伺服器，但 MCP 伺服器仍然是 MCP 客戶端的授權伺服器。因為 MCP 伺服器需要向 MCP 客戶端簽發自己的訪問令牌。

在我看來，這種情況似乎更適合處理 MCP 伺服器代理 MCP 客戶端（用戶）訪問第三方資源（如 Github repo）的情況，而不是 MCP 伺服器代理 MCP 客戶端（用戶）訪問其自己的資源。

總之，根據協議，MCP 伺服器在 OAuth 中扮演授權伺服器和資源伺服器的角色。

接下來，讓我們討論 MCP 伺服器作為授權伺服器和資源伺服器的責任。

MCP 伺服器作為授權服務

當 MCP 伺服器作為授權伺服器時，這意味著 MCP 客戶端的最終用戶在 MCP 伺服器上擁有自己的身份。MCP 伺服器負責對此最終用戶進行身份驗證，並向此最終用戶簽發訪問令牌，以便訪問 MCP 伺服器資源。

上述 MCP 授權規範要求的與授權相關的介面意味著 MCP 伺服器必須提供授權伺服器的實現。

然而，在 MCP 伺服器上實施授權伺服器功能對於開發人員來說是一個重大挑戰。一方面，大多數開發人員可能不熟悉與 OAuth 相關的概念。另一方面，實施授權伺服器時有許多細節需要考慮。如果開發人員不來自相關領域，他們可能會在實施過程中引入安全問題。

不過，協議本身並不限制 MCP 伺服器僅自行實施授權伺服器功能。開發人員可以完全將這些授權相關的端點重定向或代理到其他授權伺服器。對於 MCP 客戶端來說，這與 MCP 伺服器自行實施授權伺服器功能並無不同。

你可能會想，這種方法是否應使用上面提到的委派第三方授權方法？

在我看來，這主要取決於你所依賴的第三方授權服務的用戶是否與 MCP 伺服器的最終用戶相同。這意味著第三方授權服務簽發給你的訪問令牌將由你的 MCP 伺服器直接使用。

如果是，那麼你可以完全在你的 MCP 伺服器中將授權相關介面轉發到第三方授權服務。
如果不是，那麼你應該使用規範中指定的委派第三方授權方法。你需要在 MCP 伺服器中維護 MCP 伺服器自行簽發的訪問令牌和第三方授權服務簽發的訪問令牌之間的映射關係。

我認為協議中指定的委派第三方授權方法在實際應用場景中有點模糊。協議似乎讓第三方幫助 MCP 伺服器完成授權過程，但仍需要 MCP 伺服器向 MCP 客戶端簽發自己的訪問令牌。這實際上意味著 MCP 伺服器仍然承擔作為授權伺服器簽發訪問令牌的責任，這對於開發人員來說並沒有更加方便。我認為這可能是因為協議的作者考慮到直接將第三方訪問令牌返回給 MCP 客戶端可能會帶來一些安全問題（如洩漏/濫用等）。

從我的經驗來看，協議中指定的委派第三方授權方法最合適的場景應該是“用戶授權 MCP 伺服器訪問第三方資源”的場景。例如，MCP 伺服器需要訪問用戶的 Github Repo，並將 Repo 的代碼部署到代碼部署平台。在這種情況下，用戶需要授權 MCP 伺服器訪問他們的 Github Repo 以及訪問代碼部署平台。

在這種場景中，MCP 伺服器是 MCP 客戶端的授權伺服器，因為最終用戶在 MCP 伺服器上擁有自己的身份。對於第三方資源（在本例中為 Github），MCP 伺服器是第三方客戶端，它需要獲得用戶授權以訪問用戶在 Github 上的資源。在 MCP 客戶端和 MCP 伺服器之間，以及 MCP 伺服器和第三方資源之間，用戶身份是分開的。這意味著在 MCP 伺服器中維護 MCP 伺服器自行簽發的訪問令牌和第三方授權服務簽發的訪問令牌之間的映射關係是有意義的。

所以協議中的委派第三方授權協議應解決“用戶如何授權 MCP 伺服器訪問用戶在第三方資源伺服器上的資源”的問題。

MCP 伺服器作為資源伺服器

當 MCP 伺服器作為資源伺服器時，MCP 伺服器需要驗證 MCP 客戶端的請求是否攜帶有效的訪問令牌。MCP 伺服器將根據訪問令牌的範圍決定是否允許 MCP 客戶端訪問特定資源。

從 MCP 的定義來看，MCP 伺服器提供的資源應該是 MCP 客戶端使用的工具。在這種情況下，MCP 伺服器只需要決定是否向用戶提供訪問某些工具的權限。

但在現實場景中，MCP 伺服器提供的這些工具還需要與 MCP 伺服器服務提供者本身的資源伺服器交互。此時，MCP 伺服器從客戶端請求中獲得的訪問令牌需要用來訪問其自己的資源伺服器。在大多數情況下，MCP 伺服器和工具後面的資源伺服器是同一開發者。MCP 伺服器只是為 MCP 客戶端提供的其自身後端資源的介面。此時，MCP 伺服器可以與後端資源共享由一個授權伺服器簽發的相同訪問令牌。

在這種情況下，與其說 MCP 伺服器是一個資源伺服器，提供工具和它自己的服務，倒不如說現有資源伺服器通過為 MCP 客戶端提供工具變成了 MCP 伺服器。

將自己資源伺服器提供的資源包含在 MCP 伺服器提供的資源中更多是出於現實場景的考慮。但我個人還是更喜歡 MCP 伺服器提供的資源只有 MCP 客戶端使用的工具，而工具依賴的資源應該是 MCP 伺服器從其他資源伺服器（包括第一和第三方）獲得的資源。這樣可以涵蓋所有現實場景。

MCP 授權如何運作

了解 MCP 伺服器作為授權伺服器和資源伺服器的責任後，我們可以知道 MCP 授權具體如何工作：

動態客戶端註冊

該規範還定義了授權伺服器如何識別客戶端。OAuth 2.1 提供了動態客戶端註冊協議，允許 MCP 客戶端自動獲取 OAuth 客戶端 ID，而無需手動用戶干預。

根據該規範，MCP 伺服器應支援 OAuth 2.0 的動態客戶端註冊協議。這樣，MCP 客戶端可以自動註冊新伺服器以獲得 OAuth 客戶端 ID。該方法在 MCP 場景中受到推薦主要因為：

MCP 客戶端無法提前知道所有可能的伺服器
手動註冊會給用戶帶來麻煩
它使得與新伺服器的連接變得無縫
伺服器可以實施它們自己的註冊政策

然而，從實際的角度來看，我對動態客戶端註冊在 MCP 場景中的應用有以下幾點想法：

在實際的 OAuth 服務實踐中，客戶端通常與特定業務應用一對一對應，動態創建客戶端可能不利於在 OAuth 服務中有效管理相關資源（用戶、應用等）。OAuth 服務提供商通常希望對連接的客戶端有清楚的控制，而不是讓任何客戶端隨意註冊為客戶端。
許多 OAuth 服務不推薦或允許用戶動態創建客戶端，因為這可能會導致濫用服務。大多數成熟的 OAuth 服務提供商（如 GitHub、Google 等）要求開發者通過其開發者控制台手動註冊客戶端，可能還需要提供應用的詳細信息、回調 URL 等。
手動註冊 OAuth 客戶端實際上是開發過程中的一次性工作，不是每個最終用戶都需要做的事情，不會對開發人員造成很大負擔。
對於公共客戶端（如原生應用、單頁應用等），我們有更安全的方法來實施 OAuth 流而無需動態註冊。客戶端 ID 結合 PKCE（代碼交換的證明密鑰）可以為公共客戶端提供足夠安全的 OAuth 流，不需動態創建客戶端。
儘管協議指出使用動態客戶端註冊可以避免客戶端需要提前知道客戶端 ID，但實際上，MCP 客戶端總是需要提前知道遠程 MCP 伺服器的地址。如果是這樣，指定客戶端 ID 同時傳入遠程 MCP 伺服器地址不會帶來額外的麻煩。或者，我們還可以為 MCP 客戶端創建一個尋求 MCP 伺服器以獲取客戶端 ID 的約定，這不是一項困難的任務。

雖然動態客戶端註冊在理論上為 MCP 生態系統提供了靈活性，但在實際實施中，我們可能需要考慮是否真的需要這種動態註冊機制。對於大多數服務提供商來說，手動創建和管理 OAuth 客戶端可能是一種更可控且更安全的方法。

總結

本文深度分析了 MCP 授權規範的設計理念和實施挑戰。作為一個基於 OAuth 2.1 的授權框架，該規範旨在解決遠程 MCP 伺服器如何代表用戶訪問用戶資源的關鍵問題。

通過對 MCP 伺服器作為授權伺服器和資源伺服器的雙重角色以及動態客戶端註冊和第三方授權委派等機制的優缺點的詳細討論，本文提供了來自實施認證器個人經驗的思考和建議。

值得注意的是 MCP 授權規範仍在演進中。作為 Logto 團隊的一員，我們將繼續關注此規範的最新發展，並在實踐中不斷優化我們的實施方案，以促進 AI 模型與外部服務之間的安全互動。

MCP 授權規範概述#

MCP 伺服器作為授權服務#

MCP 伺服器作為資源伺服器#

MCP 授權如何運作#

動態客戶端註冊#

總結#

MCP 授權規範概述#

MCP 伺服器作為授權服務#

MCP 伺服器作為資源伺服器#

MCP 授權如何運作#

動態客戶端註冊#

總結#

MCP 授權規範概述

MCP 伺服器作為授權服務

MCP 伺服器作為資源伺服器

MCP 授權如何運作

動態客戶端註冊

總結

MCP 授權規範概述

MCP 伺服器作為授權服務

MCP 伺服器作為資源伺服器

MCP 授權如何運作

動態客戶端註冊

總結