Building Multi-Tenant MCP Servers with OAuth: Secure Integration for Claude and ChatGPT

Title

Building Multi-Tenant MCP Servers with OAuth: Secure Integration for Claude and ChatGPT

Meta Description

This article explains how to build an OAuth-enabled multi-tenant MCP server to securely connect SaaS products to Claude and ChatGPT. It covers the three pillars of authentication, token security, and tenant isolation, with a full tutorial and open-source code.

Article Content

When customers want their SaaS product to be accessible through Claude and ChatGPT, connecting an AI assistant to an API isn't hard — the hard part is ensuring the model can only access the right tenant's data. Based on a complete tutorial and open-source repository shared on Reddit, this article breaks down how to build an OAuth-enabled multi-tenant MCP server.

Why Do Multi-Tenant MCP Servers Need OAuth?

Many SaaS products are themselves multi-tenant architectures, with strict data isolation between customers. Once the backend is exposed to AI agents via MCP (Model Context Protocol), a core problem must be solved: the model must not be able to access another tenant's data without authorization. A simple API connection can't meet this requirement, because the AI model itself is untrusted — it can be manipulated or make mistakes, and thereby invoke resources that don't belong to the current user.

The original author points out that their product is multi-tenant, so they built a custom MCP server that calls the existing backend API, deployed it on Arcade Cloud, and integrated OAuth via Clerk so customers can log in with their existing credentials. The key design: the model never handles access tokens and cannot choose which user it represents. On every call, the backend API validates the OAuth token and enforces workspace membership and plan-tier permissions.

MCP (Model Context Protocol) is a protocol proposed and open-sourced by Anthropic to standardize how AI models connect to external tools and data sources. It defines a client-server architecture: AI applications (such as Claude Desktop or IDE plugins) act as clients and extend model capabilities through the Resources, Tools, and Prompts exposed by MCP servers. The value of MCP lies in abstracting "how a model calls external systems" into a unified interface, avoiding the need to build a separate integration for every AI platform. But the protocol itself does not prescribe an authentication or authorization model, which means security responsibilities such as tenant isolation and token management fall entirely on the MCP server implementer — this is precisely the fundamental reason OAuth is needed in this article.

OAuth 2.0 is an authorization framework that allows third-party applications to obtain limited access to a user's resources without acquiring the user's password. Its core roles include the resource owner (the user), the client (here, the MCP server), the authorization server (such as Clerk), and the resource server (the backend API). OAuth represents the authorization result through an access token and supports scopes to limit the range of permissions. In multi-tenant scenarios, OAuth tokens typically carry user identity and tenant affiliation information, enabling the backend to independently verify "who is accessing which workspace" on every request rather than relying on the model to self-report its identity.

The Three Independent Concerns of Authentication

During implementation, the author found that the trickiest part was breaking authentication down into three distinct concerns, each with a different purpose and an independent token or verification flow:

• Gateway authentication: handles identity verification before the request reaches the MCP server.
• API authorization: when calling the backend API, verifies whether the request has permission to access a specific resource.
• Browser session verification: ensures the authenticity of the user session and prevents token leakage or misuse.

Conflating these three leads to confusion. The tutorial explains in detail how they work together and how to implement each one separately in code. This separation makes security boundaries clear and reduces the risk of unauthorized access.

Clerk is an authentication and user management platform for modern web applications, offering hosted login interfaces, OAuth provider integration, session management, and JWT issuance. In this case, Clerk acts as the OAuth authorization server: after customers log in with their existing credentials, Clerk issues an access token to the MCP server, and the token can embed claims such as the user ID and organization/workspace ID. The MCP server then carries that token when calling the backend API, and the backend confirms tenant affiliation by verifying the signature and claims. Using a managed identity platform saves the work of building your own authorization server, but it also requires developers to understand the token lifecycle, refresh mechanisms, and the trust boundaries of claim contents — otherwise unauthorized access can still occur.

Key Security Mechanism: The Model Never Touches the Token

The author emphasizes a critical design principle: the model does not touch access tokens and cannot decide whose identity it acts under. This means that even when a user interacts with the agent through Claude or ChatGPT, token acquisition and transmission happen entirely on the server side — the model can only express intent, while the server strictly limits what operations can be performed based on the user session.

The specific flow is: after the user logs in via OAuth, the MCP server holds the access token; when the model requests a call to the backend API, the server uses that token to make the request, and the backend API validates the token and checks the user's workspace membership and plan permissions. In this way, the model cannot forge identity or escalate privileges, and tenant isolation is guaranteed.

Implementation Overview and Resources

The author provides a complete open-source implementation, including a code repository and a step-by-step tutorial. The repository is at: https://github.com/manveer/multi-tenant-mcp-server-oauth , and the tutorial is at: https://manveerc.substack.com/p/multi-tenant-mcp-server-oauth . The implementation is deployed on Arcade Cloud and uses Clerk to handle OAuth, and can serve as a reference architecture.

For developers considering exposing a multi-tenant backend via MCP, the author poses an open question: how do you handle tenant isolation and user authentication? This reflects that the field is still evolving rapidly and best practices have not yet been standardized.

Summary and Takeaways

This case demonstrates that when integrating AI agents with SaaS products, multi-tenant security cannot be ignored. By separating authentication concerns, ensuring the model never touches tokens, and enforcing fine-grained permission control at the API layer, data leakage can be effectively prevented. As the MCP protocol becomes more widespread, similar OAuth integration patterns may become standard practice.

One-line Summary

A breakdown of how to build a multi-tenant MCP server with OAuth to ensure AI models don't access tenant data without authorization.

Paragraph Summary

Based on a tutorial and open-source repository shared on Reddit, this article explains how to build an OAuth-enabled multi-tenant MCP server so that SaaS products can be securely accessed through Claude and ChatGPT. The core issue is that AI models are untrusted and must not be allowed to access other tenants' data without authorization. The author splits authentication into three independent concerns — gateway authentication, API authorization, and browser session verification — and adheres to a key principle: the model never touches access tokens and cannot choose which user it represents. Every backend API call validates the OAuth token and enforces workspace membership and plan permissions. The implementation is deployed on Arcade Cloud with Clerk handling OAuth, and provides complete open-source code and a tutorial as a reference architecture.