繁體中文（香港）

mcp 訪問控制
mcp rbac
個人訪問令牌

提升你的業務：使用訪問控制將 AI 工具連接到現有服務

學習如何通過使用個人訪問令牌和模型上下文協議（MCP）安全地將 AI 工具連接到現有服務，並獲得完整源代碼和實用示例。

Yijun

Developer

3/5/2025

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

歡迎閱讀有關使用訪問控制將 AI 工具連接到現有服務的指南！

我們將探討如何讓現有服務為 AI 工具做好準備，尤其是通過與 LLM（使用 Model Context Protocol) 和各種 AI 代理的集成來解決訪問控制挑戰。

通過本指南，你將獲得：

無縫的 AI 集成：學習如何將 AI 工具連接到你的服務，使你的數據和功能在 AI 環境中可用
增強的 API 安全性：改進你的 API 接口，用有效的訪問控制保護數據和用戶隱私
為用戶提供個性化的 AI 體驗：通過個人訪問令牌為每個用戶創造獨特的 AI 輔助體驗

我們提供完整的教學資源、完整演示項目源代碼（包括前端、後端和 MCP 服務器），甚至實用指南，幫助你從頭開始建立 AI 準備服務。

以下是此指南如何改善你的業務：

競爭優勢：提升你的服務的技術能力和用戶體驗，以在競爭激烈的市場中脫穎而出
用戶價值提升：讓用戶通過 AI 工具發現你的產品的更深層次價值，提高留存率和滿意度
未來準備服務：將你的服務無縫集成到 AI 生態系統中，準備迎接即將到來的 AI 驅動業務景觀，並開辟創新增長路徑

讓我們開始吧！

什麼是 MCP，它如何將 AI 工具連接到你的服務

MCP（模型上下文協議）是一個開放的、通用的協議，標準化了應用程序向大型語言模型（LLMs）提供上下文信息的方式。

MCP 由幾個關鍵組件組成，這些組件一起工作以使 AI 工具能夠訪問你的服務：

在本指南中，你只需要知道 MCP 服務器是你的服務和 AI 工具之間的關鍵連接點。它負責為 LLM 提供一系列工具，而這些工具將與你自己的服務互動。有關 MCP 的更多詳細信息，你可以參考什麼是 MCP（模型上下文協議）及其如何運作。在這裡，我們將只關注 MCP 服務器。

我們將使用一個集成了基於角色的訪問控制（RBAC）策略的內容管理系統（CMS）作為示例。我們將為它創建一個 MCP 服務器，並定義一個 get-available-article-count 工具，允許 LLM 檢索 CMS 中當前用戶可用的文章數量：

這是將 MCP 服務器連接到你的服務的關鍵代碼。在此工具的實現中，它向服務的 api/articles 端點發送請求並返回結果。

然而，這還遠遠不夠，因為你的服務 API 可能不是公開的。每個端點都需要訪問控制，不同的用戶可以訪問不同的資源和數據。

接下來，我們將討論如何向你的服務添加訪問控制。

如何為 MCP 服務器實施訪問控制

重要的是要理解，通過 AI 工具訪問你的系統的用戶是可能直接使用你的系統的同一個人——MCP 服務器在他們通過 AI 工具互動時代表他們。

因此，當用戶通過 AI 工具訪問你的服務時，會出現兩個實際的訪問控制挑戰：

MCP 服務器如何像用戶一樣登錄到你的系統？
你的系統是否應該重新設計其整個訪問控制機制以適應 MCP 服務器？這將是一個重大的成本和努力，特別是當你的原始系統已經有自己的身份驗證機制時

解決這些問題的關鍵是：

用戶如何才能讓 MCP 服務器不使用他們的憑據和交互式登錄來授予訪問你的服務的權限？

如果你能解決這個問題，你就可以通過 MCP 服務器直接與你的服務互動，而你的服務可以繼續使用之前為用戶設計的訪問控制機制，無需為 MCP 服務器重新設計一個新系統！

但是這可能嗎？

當然可以！我們可以通過使用個人訪問令牌來完美解決這個問題！

個人訪問令牌（PATs）提供了一種安全的方法，讓用戶不使用他們的憑據和交互式登錄來授予訪問令牌。這對於必須程序訪問資源的 CI/CD、腳本或應用程序非常有用。

這是工作流程的樣子：

所以，只要你的系統支持個人訪問令牌（PAT），你就可以完美地解決 AI 工具和你現有服務之間的訪問控制問題，而無需重新設計你的身份驗證機制，並同時確保用戶的數據安全和隱私保護。

現在，讓我們看看如何實際實施這一點。

MCP 服務器訪問控制實施

在本節中，我們將使用現有的 CMS 系統作為基礎來為 MCP 服務器實施訪問控制。

你可以檢出RBAC 示例的完整 CMS 教程和源代碼，但這不是必需的，我們將涵蓋這裡所有的基本原則。

CMS 示例基於 Logto，一個受歡迎的開源身份平台，提供全面的身份驗證和授權解決方案，但技術實施不是本文的重點。

設計你的服務的權限和訪問控制策略

實施訪問控制的第一步是為你的系統設計權限和訪問控制策略。

在我們的 CMS 示例中，我們根據 RBAC（基於角色的訪問控制）設計了以下 API 端點，並指定了訪問每個端點所需的權限：

端點	訪問控制邏輯
GET /api/articles	- 任何擁有 `list:articles` 權限，或作者可以查看自己的文章
GET /api/articles/:id	- 任何擁有 `read:articles` 權限，或文章的作者
POST /api/articles	- 任何擁有 `create:articles` 權限
PATCH /api/articles/:id	- 任何擁有 `update:articles` 權限，或文章的作者
DELETE /api/articles/:id	- 任何擁有 `delete:articles` 權限，或文章的作者
PATCH /api/articles/:id/published	- 只有擁有 `publish:articles` 權限的用戶

系統的權限設計如下：

權限	描述
list:articles	查看系統中所有文章的列表
read:articles	閱讀任何文章的完整內容
create:articles	創建新文章
update:articles	修改任何文章
delete:articles	刪除任何文章
publish:articles	更改發佈狀態

基於這些權限，我們為 CMS 系統定義了以下角色：

權限/角色	👑 管理員	📝 發佈者	✍️ 作者
描述	完整的系統訪問以進行完整的內容管理	可以查看所有文章並控制發佈狀態	可以在系統中創建新文章
list:articles	✅	✅	❌
read:articles	✅	✅	❌
create:articles	✅	❌	✅
update:articles	✅	❌	❌
delete:articles	✅	❌	❌
publish:articles	✅	✅	❌

註：作者無論角色權限如何，對自己文章自動擁有讀取/更新/刪除的權限。

接下來，我們將為系統中的用戶分配角色（以 CMS 演示為例）：

用戶	角色
Alex	管理員
Bob	發佈者
Charlie	作者

在 Logto 中，如上文 RBAC 實踐 文章所述，我們已為用戶設置角色。

Logto 角色

將訪問控制策略應用到你的服務 API

這是用戶如何登錄我們的 CMS 示例的：

因此，將訪問控制應用到你的服務 API 就像在第 9 步中添加一個中間件來驗證訪問令牌並檢查權限一樣簡單。

核心實現如下（檢查完整實現請看 RBAC 範例 - 後端）：

並將中間件應用到需要身份驗證的 API 端點：

我們現在已經向 CMS 系統添加了訪問控制並為用戶分配了角色。

用戶登錄並獲取 CMS API 的訪問令牌後，他們可以使用該令牌訪問 CMS API。訪問令牌包含用戶的權限信息。這讓我們能夠根據用戶權限控制返回的數據。

我們的下一步是實施 MCP 服務器以使用個人訪問令牌。

理解個人訪問令牌如何代表用戶

參考上述 CMS 認證流程，用戶登錄後會獲取 CMS API 的訪問令牌。這個訪問令牌是他們訪問 CMS API 的憑據。

我們只需要獲取類似於用戶登錄後的訪問令牌。然後我們就可以用它來訪問 CMS API。

這時個人訪問令牌進入了。我們可以通過它獲取與用戶通常登錄後獲得的相同類型的訪問令牌。

這是我們需要做的：

為用戶創建一個個人訪問令牌
使用這個個人訪問令牌從認證服務的令牌端點請求交換令牌。這會給我們一個類似於用戶登錄後獲得的訪問令牌
在我們的 MCP 服務工具中使用這個訪問令牌訪問 CMS API

在這個例子中，我們以 Logto 為例，因為 Logto 支持個人訪問令牌和令牌交換。如果你不使用 Logto，可以遵循這個方法來實施自己的個人訪問令牌支持。

為你的用戶創建個人訪問令牌

在 Logto Console > 用戶管理中，你可以從用戶的詳細信息頁創建個人訪問令牌：

在 Logto 控制台中創建個人訪問令牌

創建個人訪問令牌時，你可以根據需要設置其過期時間。

在 MCP 服務器中使用個人訪問令牌

現在我們有了用戶的個人訪問令牌，我們可以在 MCP 服務器中使用它。

首先，讓我們按照 Logto 的個人訪問令牌文檔，我們將從 Logto 的令牌端點獲取訪問 CMS API 的訪問令牌。你可以在這裡檢查完整的源代碼：這裡。

在 MCP 服務器中，我們使用 exchangeAccessToken 函數獲得的訪問令牌來從 CMS API 獲取數據。

這樣，MCP 服務器無需用戶的登錄憑據即可訪問 CMS API，而是使用用戶的個人訪問令牌。

你可以在這裡找到完整的代碼：RBAC 示例 - mcp-server。

若要了解如何在本地將此 MCP 服務器與 Claude Desktop 部署，請查看：MCP 服務器部署指南。

你還可以將此服務器部署到各種 AI IDE，如 Cursor、 Cline、 Windsurf 等。

測試訪問控制

讓我們在 Claude Desktop 中測試這個實施。

在我們的 CMS 中，Alex 和 Charles 各自創建了一篇文章。

由於 Alex 擁有管理員角色，他可以查看所有文章。而 Charles 作為作者，只能看到自己的文章。

當我們問 Claude 有多少可用文章時，Claude 會使用 get-available-article-count 工具並詢問我們的許可：

使用工具的請求

當我們在 MCP 中使用 Alex 的個人訪問令牌並詢問 Claude 關於可用文章的數量時，Claude 會調用 get-available-article-count 工具並告訴我們有 2 篇文章。

Alex 的結果

當我們切換到 Charles 的個人訪問令牌並詢問相同的問題時，Claude 告訴我們只有 1 篇文章。

Charles 的結果

太棒了！我們已經成功地使用個人訪問令牌訪問了 CMS API 並獲得了正確的數據。

這正是我們想要的：我們為每個用戶創建一個個人訪問令牌，當用戶使用他們的令牌配置 MCP 服務器時，我們為他們創建個性化的 AI 體驗。

讓我幫助你撰寫總結部分：

總結

在本指南中，我們探討了如何在維持適當訪問控制的同時將 AI 工具連接到現有服務。我們使用具有 RBAC 實施的 CMS 系統演示了如何通過個人訪問令牌（PATs）優雅地解決身份驗證挑戰。

你可以在我們的 RBAC 範例庫中找到此實施的完整源代碼，其中包括 CMS 後端、前端和 MCP 服務器的實現。

向用戶分發 MCP 服務器時，請記得使個人訪問令牌可配置。這允許每個用戶：

在 MCP 服務器中配置他們自己的 PAT
根據他們的具體權限訪問資源
獲得反映他們角色和訪問級別的個性化 AI 體驗

這種方法確保 AI 集成保持安全，同時為每位用戶提供根據其權限和系統角色量身定制的體驗。

希望你在 AI 集成之旅中取得巨大成功！願你的服務隨著這些新的 AI 能力蓬勃發展和增長！🚀

什麼是 MCP，它如何將 AI 工具連接到你的服務#

如何為 MCP 服務器實施訪問控制#

MCP 服務器訪問控制實施#

設計你的服務的權限和訪問控制策略#

將訪問控制策略應用到你的服務 API#

理解個人訪問令牌如何代表用戶#

為你的用戶創建個人訪問令牌#

在 MCP 服務器中使用個人訪問令牌#

測試訪問控制#

總結#