多租户MCP服务器与OAuth集成实战：安全接入Claude和ChatGPT

当客户希望自己的SaaS产品能通过Claude和ChatGPT访问时，将AI助手连接到API并不难，难的是确保模型只能访问正确的租户数据。本文基于Reddit上分享的一个完整教程和开源仓库，深入拆解如何构建支持OAuth的多租户MCP服务器。

为什么多租户MCP服务器需要OAuth？

许多SaaS产品本身就是多租户架构，不同客户的数据严格隔离。一旦通过MCP（Model Context Protocol）将后端暴露给AI智能体，就必须解决一个核心问题：模型不能越权访问其他租户的数据。简单的API连接无法满足这一要求，因为AI模型本身不可信，它可能被诱导或出错，从而调用不属于当前用户的资源。

原帖作者指出，他们的产品是多租户的，因此他们构建了一个自定义的MCP服务器，该服务器调用现有的后端API，并部署在Arcade Cloud上，同时通过Clerk集成OAuth，让客户可以使用现有凭据登录。关键设计在于：模型从不处理访问令牌，也无法选择它代表哪个用户。每次调用时，后端API都会验证OAuth令牌，并强制执行工作区成员资格和套餐层级权限。

MCP（Model Context Protocol） 是由 Anthropic 提出并开源的协议，用于标准化 AI 模型与外部工具、数据源之间的连接方式。它定义了一套客户端-服务器架构：AI 应用（如 Claude Desktop、IDE 插件）作为客户端，通过 MCP 服务器暴露的资源（Resources）、工具（Tools）和提示（Prompts）来扩展模型能力。MCP 的价值在于把“模型如何调用外部系统”抽象为统一接口，避免为每个 AI 平台重复开发集成。但协议本身不规定认证与授权模型，这意味着租户隔离、令牌管理等安全责任完全落在 MCP 服务器实现者身上——这正是本文需要引入 OAuth 的根本原因。

OAuth 2.0 是一种授权框架，允许第三方应用在不获取用户密码的前提下，获得对用户资源的有限访问权限。其核心角色包括资源所有者（用户）、客户端（此处为 MCP 服务器）、授权服务器（如 Clerk）和资源服务器（后端 API）。OAuth 通过访问令牌（access token）表示授权结果，并支持作用域（scope）限制权限范围。在多租户场景中，OAuth 令牌通常携带用户身份与租户归属信息，使后端能够在每次请求时独立验证“谁在访问哪个工作区”，而不依赖模型自报身份。

认证的三个独立关注点

在实现过程中，作者发现最棘手的部分是将认证拆解为三个不同的关注点，每个关注点有不同的目的和独立的令牌或验证流程：

• 网关认证（Gateway authentication）：处理请求到达MCP服务器之前的身份验证。
• API授权（API authorization）：在调用后端API时，验证请求是否有权限访问特定资源。
• 浏览器会话验证（Browser session verification）：确保用户会话的真实性，防止令牌泄露或滥用。

将这三者混为一谈会导致混乱。教程详细解释了它们如何协同工作，以及如何在代码中分别实现。这种分离设计使得安全边界清晰，降低了越权风险。

Clerk 是一个面向现代 Web 应用的身份验证与用户管理平台，提供托管式的登录界面、OAuth 提供商集成、会话管理以及 JWT 签发能力。在本案例中，Clerk 充当 OAuth 授权服务器：客户使用现有凭据登录后，Clerk 向 MCP 服务器签发访问令牌，令牌中可嵌入用户 ID、组织/工作区 ID 等声明（claims）。MCP 服务器随后在调用后端 API 时携带该令牌，后端通过验证签名与声明来确认租户归属。使用托管身份平台可以省去自建授权服务器的工作，但也要求开发者理解令牌的生命周期、刷新机制以及声明内容的可信边界，否则仍可能出现越权。

关键安全机制：模型永不接触令牌

作者强调了一个至关重要的设计原则：模型不接触访问令牌，也不能决定自己以谁的身份行事。这意味着，即使用户通过Claude或ChatGPT与智能体交互，令牌的获取和传递完全在服务器端完成，模型只能发出意图，而服务器根据用户会话严格限制可执行的操作。

具体流程是：用户通过OAuth登录后，MCP服务器持有访问令牌；当模型请求调用后端API时，服务器使用该令牌发起请求，后端API验证令牌并检查用户的工作区成员资格和套餐权限。这样，模型无法伪造身份或提升权限，租户隔离得以保证。

实现概览与资源

作者提供了完整的开源实现，包括代码仓库和逐步教程。仓库地址为：https://github.com/manveer/multi-tenant-mcp-server-oauth ，教程地址为：https://manveerc.substack.com/p/multi-tenant-mcp-server-oauth 。该实现基于Arcade Cloud部署，使用Clerk处理OAuth，可作为一种参考架构。

对于正在考虑通过MCP暴露多租户后端的开发者，作者提出了一个开放问题：你如何处理租户隔离和用户认证？这反映了该领域仍在快速发展中，最佳实践尚未统一。

总结与启示

这个案例展示了在AI智能体与SaaS产品集成时，多租户安全不可忽视。通过分离认证关注点、确保模型不接触令牌、以及在API层实施细粒度权限控制，可以有效防止数据泄露。随着MCP协议的普及，类似的OAuth集成模式可能会成为标准做法。