增强你的业务:通过访问控制将 AI 工具连接到你现有的服务
了解如何通过使用个人访问令牌(Personal Access Tokens)和模型上下文协议(Model Context Protocol,MCP)安全地将 AI 工具连接到你的现有服务,获取完整的源代码和实用示例。
了解如何通过使用个人访问令牌(Personal Access Tokens)和模型上下文协议(Model Context Protocol,MCP)安全地将 AI 工具连接到你的现有服务,获取完整的源代码和实用示例。
欢迎来到通过访问控制将 AI 工具连接到你现有服务的指南!
我们将探讨如何使你的现有服务为 AI 工具做好准备,特别是通过与 LLM(使用 模型上下文协议)和各种 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 可能不是公共的。每个端点都需要访问控制,不同的用户可以访问不同的资源和数据。
接下来,我们将讨论如何为你的服务添加访问控制。
理解通过 AI 工具访问你的系统的用户与直接使用你的系统的用户是相同的非常重要——MCP 服务器在他们通过 AI 工具交互时充当他们的代表。
因此,当用户通过 AI 工具访问你的服务时,会出现两个实际的访问控制挑战:
解决这些问题的关键是:
用户如何可以让 MCP 服务器授予访问服务的权限而不使用他们的凭据和交互式登录?
如果你能解决这个问题,你可以通过 MCP 服务器直接与你的服务进行交互,而你的服务可以继续使用先前为用户设计的访问控制机制,而不需要仅仅为 MCP 服务器重新设计一个新系统!
但这可能吗?
当然可以!我们可以通过使用 个人访问令牌 完美地解决这个问题!
个人访问令牌(PATs)为用户提供了一种安全的方法来授权访问令牌,而不使用他们的凭据和交互式登录。这对于需要以程序化方式访问资源的 CI/CD、脚本或应用程序很有用。
工作流如下所示:
因此,只要你的系统支持个人访问令牌(PAT),你就可以在不重新设计身份验证机制的情况下完美解决 AI 工具与现有服务之间的访问控制挑战,同时确保用户的数据安全和隐私保护。
现在,让我们看看如何在实践中实现这一点。
在本节中,我们将使用现有的 CMS 系统作为基础为 MCP 服务器实现访问控制。
你可以查看完整的 CMS 示例教程和源代码 RBAC 原则实践:为你的应用程序实现安全授权,但这不是必需的,我们将在这里介绍所有的基本原则。
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 原则实践 文章中所述,我们为我们的用户设置了角色。

以下是用户如何登录到我们的 CMS 示例:
因此,将访问控制应用于你的服务 API 就像在步骤 9 中添加一个中间件来验证访问令牌并检查权限一样简单。
核心实现如下(查看完整实现 RBAC 示例 - 后端):
并将中间件应用于需要身份验证的 API 端点:
我们现在已经向我们的 CMS 系统添加了访问控制,并为我们的用户分配了角色。
在用户登录并获取 CMS API 的访问令牌后,他们可以使用此令牌访问 CMS API。访问令牌包含用户的权限信息。这使我们能够根据用户权限控制返回哪些数据。
我们的下一步是实现使用个人访问令牌的 MCP 服务器。
参考上面的 CMS 身份验证流程,用户在登录后获取 CMS API 的访问令牌。这个访问令牌是他们访问 CMS API 的凭据。
我们只需要获取一个类似于用户登录后获取的访问令牌。然后我们就可以使用它来访问 CMS API。
这就是个人访问令牌的用武之地。它们帮助我们获取用户通常在登录后获取的相同类型的访问令牌。
我们需要做的是:
在这个示例中,我们使用 Logto 进行演示,因为 Logto 支持个人访问令牌和令牌交换。如果你不使用 Logto,你可以按照此方法实现你自己的个人访问令牌支持。
在 Logto 控制台 > 用户管理中,你可以从用户详情页面为用户创建个人访问令牌:

在创建个人访问令牌时,你可以根据需要设置其过期时间。
现在我们有了用户的个人访问令牌,我们可以在我们的 MCP 服务器中使用它。
首先,让我们按照 Logto 的 个人访问令牌文档,我们将从 Logto 的令牌端点获取一个用于访问 CMS API 的访问令牌。你可以查看完整的源代码 此处。
在 MCP 服务器中,我们使用 exchangeAccessToken 函数获取的访问令牌从 CMS API 获取数据。
这样,MCP 服务器无需用户登录凭据即可访问 CMS API,而是使用用户的个人访问令牌。
你可以在 RBAC 示例 - mcp-server 中找到完整的代码。
要了解如何在 Claude Desktop 中本地部署此 MCP 服务器,请查看: 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 篇文章。

当我们切换到 Charles 的个人访问令牌并询问相同的问题时,Claude 告诉我们只有一篇文章。

太棒了!我们已经成功地使用个人访问令牌访问 CMS API 并获取了正确的数据。
这正是我们想要的:我们为每个用户创建一个个人访问令牌,当用户使用他们的令牌配置他们的 MCP 服务器时,我们为他们创建一个个性化的 AI 体验。
让我帮助你编写总结部分:
在本指南中,我们探讨了如何在维护适当的访问控制的情况下将 AI 工具连接到你的现有服务。我们使用一个带有 RBAC 实现的 CMS 系统进行演示,展示了个人访问令牌(PATs)如何优雅地解决身份验证挑战。
你可以在我们的 RBAC 示例库 中找到此实现的完整源代码,其中包括 CMS 后端、前端和 MCP 服务器的实现。
在分发你的 MCP 服务器给用户时,记得让个人访问令牌可配置。这样每个用户可以:
这种方法确保了你的 AI 集成在保持安全的同时,为每个用户提供基于他们权限和角色的定制体验。
祝愿你在展开这种 AI 集成旅程时取得巨大成功!愿你的服务在这些新的 AI 功能支持下蓬勃发展,欣欣向荣! 🚀