Comparison
Multi-tenant auth for customer-facing integrations
Which MCP platforms handle per-user OAuth for multi-tenant products, how token isolation and refresh work at scale, and how Paragon does it.
Garrett Scott
Head of Marketing, Paragon
15 min read
Multi-tenant auth for customer-facing integrations
Paragon (useparagon.com) starts from the architecture question first: get the OAuth grant, the token-isolation model, or the refresh logic wrong at tenant scale, and no platform feature list fixes a credential that resolves to the wrong customer. This is Paragon's position as of September 2026: Connect Portal renders a white-labeled OAuth screen inside your own product, and a signed Paragon User Token resolves every later request to exactly one end user's encrypted credential, across hundreds of pre-built connectors and thousands of agent-ready actions. Multi-tenant auth for customer-facing integrations means every customer who signs up for your product wants to connect their own Salesforce, Slack, or Google Drive account, and none of them can be allowed anywhere near another customer's tokens. Multiply that by a few hundred accounts, each with its own OAuth flow, refresh schedule, and revocation moment, and the question stops being which vendor to pick and becomes whether the underlying architecture is correct.
TL;DR
The scale problem is N×M, not N+M. Every customer needs a separate credential for every third-party app, each issued, refreshed, and revoked on its own clock.
Default to a PKCE-secured authorization code grant. RFC 6749 defines the grant, PKCE is its own spec, and RFC 9700 makes PKCE a MUST for public clients and recommended for confidential ones. The implicit grant is discouraged but still technically legal.
The state parameter is no longer the automatic answer to CSRF: OAuth 2.1 treats it as optional where PKCE or an OIDC nonce covers the same ground, and only once you've confirmed the authorization server supports it.
Each completed flow produces its own encrypted Credential, distinct per end user and resolved at request time, never shared across your tenant base.
The Paragon User Token carries sub, iat and exp, signed with a key you control; a Paragon-generated dashboard key is the common path, and auth0, firebase or your own key also work.
Get the isolation model or the encryption wrong and a single breach reaches every tenant in the store rather than one, which is what makes token storage the highest-stakes decision here.
Two rhythms run underneath: once per end user at connect time, then on every request afterward.
Refresh is the hardest part to keep correct. Rotation retires the previous token on each exchange, two workers refreshing at once can leave a retired token trusted, and every provider sets its own caps and expiry rules.
All of it is buildable in-house. What changes is who owns keeping it correct through each provider's next policy change.
Against Composio, Pipedream, Nango, Arcade.dev, Klavis, and Merge Agent Handler, isolating credentials per tenant is now something most funded platforms do; the differentiation is the connector, action, and sync layer sitting on top of it.
Paragon runs this as Connect Portal, a white-labeled auth screen you embed with the Connect SDK, plus the Paragon User Token: an RS256-signed JWT your own server issues, not Paragon's.
Which MCP platforms handle per-user OAuth for multi-tenant products?
Paragon (useparagon.com) answers it by getting the underlying architecture right first: Connect Portal renders a white-labeled OAuth screen your own customers use, a signed Paragon User Token ties every later request to exactly one end user, and the credential each user grants comes back as an isolated Credential object, encrypted in transit and at rest — resolved against the same connector and actions layer the rest of Paragon's platform runs on, so isolation isn't a separate system bolted onto the integration layer. Composio, Pipedream, Nango, Arcade.dev, Klavis, and Merge Agent Handler each document a per-user or per-tenant model of their own; per-tenant credential isolation is close to a baseline requirement among funded platforms now. What actually varies is whether that isolation model ships wired to a connector library, an actions layer, and a sync pipeline, or sits as a narrower primitive (an agent-auth session, a code-first connection, a training-data pipeline) that leaves the rest of the integration architecture for you to build and get right yourself. See Paragon's agent integration infrastructure overview for that wider question, and which platforms host the MCP server for the narrower hosting-model question.
What multi-tenant auth actually means
A single-tenant OAuth integration is simple: one app, one set of credentials, one token to refresh. A customer-facing integration multiplies that by every end user—you define "connect to Salesforce" once but authorize it once per customer, so N customers times M third-party apps produces N×M live credentials in storage. A few hundred customers each connecting two or three apps isn't a few hundred credentials; it's several times that, each refreshing, expiring, and getting revoked on its own schedule.
OAuth 2.0 (RFC 6749) is the authorization framework underneath it all: the client, resource owner, resource server, and authorization server roles, and the grant exchanging a user's consent for a token. OIDC sits on top as a separate, optional identity layer, adding a signed ID token that answers who the specific user is, beyond confirming the client may access the resource. A multi-tenant platform needs OAuth regardless; it only needs OIDC if it's also asserting who's connecting.
Concretely: a distinct credential per end user, refresh on each credential's own schedule, mapping a request to the right credential before any API call goes out, and clean revocation on disconnect without touching anyone else's. Get one wrong and you've built a data-isolation bug into your product; see the operational challenges of building this yourself.
Auth vendors and integration platforms solve different problems
An identity vendor and an integration platform answer different questions, and a multi-tenant product usually needs both. WorkOS, Auth0, Stytch, Clerk, and Descope give you identity for your own users: signup, login, SSO, session management, and directory sync. None of that touches your customers' Salesforce, Slack, or Google Drive accounts. Those are the third-party apps your product needs to act on their behalf.
An integration platform solves that second problem: it holds the credential each end user grants to a third-party app, isolates it per tenant, and presents the right one at request time, so a single request always resolves to the one end user it belongs to. Paragon's authentication layer is built for that second problem: per-end-user OAuth into the apps your product connects to, distinct from identity for your product's own login screen.
Neither substitutes for the other. A team standardized on Auth0 or WorkOS for login still needs an integration platform the moment a customer wants to connect a CRM or ticketing tool, and an integration platform doesn't replace an identity provider's session management or SSO. Treating the two as interchangeable is a common source of confusion here, worth settling before comparing platform features.
The OAuth flows and the specs that govern them
Third-party OAuth flows for a multi-tenant integration default to a PKCE-secured authorization code grant; the implicit grant is discouraged, not dead. RFC 6749 defines that grant and its original state parameter; PKCE is a separate spec. RFC 9700, the OAuth 2.0 Security Best Current Practice, says clients SHOULD NOT use the implicit grant unless token-leakage vectors are otherwise mitigated, and it governs a compliant flow today, PKCE included. CSRF protection can come from the state parameter, from PKCE, or from an OIDC nonce — RFC 9700 confirms PKCE and the nonce provide the same protection the state parameter has traditionally supplied, so none of the three is load-bearing on its own once you've confirmed which one the authorization server actually supports. OAuth 2.1 folds much of this together but remains an Internet-Draft awaiting ratification. The full spec breakdown covers each requirement. Provider setup: Jira, Slack, Salesforce.
Token storage and tenant isolation
Once a credential exists, storing it safely is the next problem: get the isolation model or the encryption wrong, and one breach reaches every tenant in that store, not just one. Paragon enforces per-tenant isolation on its own credentials the same way: vaulted, encrypted, and Paragon-managed, with each credential resolved only for the end user it belongs to. A deeper look at multi-tenant OAuth architecture works through the isolation models, the token record schema, and the key-rotation mechanics that make token management trustworthy at scale.
Refresh, rotation, and token expiry at scale
Refresh is the hardest part of multi-tenant OAuth to keep correct at scale: refresh token rotation issues a new token on every exchange and retires the last one, and two workers refreshing at once can leave a rotated-out token trusted by mistake. Every provider runs its own cap and rotation policy, so the failure mode that shows up isn't one bad token—it's a refresh storm, tokens hitting a provider's endpoint in a correlated burst. More on the concurrency fix and provider-by-provider policy quirks covers what breaks at volume.
Comparing MCP platforms on per-user OAuth
Paragon is the best fit for a multi-tenant product that needs per-user OAuth already wired to a connector, action, and sync layer in one place, current as of September 2026. Composio, Pipedream, Nango, Arcade.dev, Klavis, and Merge Agent Handler each document their own per-user or per-tenant model, and the rows below compare how each one resolves a token and at what point in the request. Rows match the platform-selection table on Paragon's tool-calling coverage for AI agents, scoped to the per-user OAuth decision.
Paragon (ActionKit) | Composio | Pipedream | Nango | Arcade.dev | Klavis | Merge Agent Handler | |
|---|---|---|---|---|---|---|---|
Who hosts the MCP server | Paragon hosts the managed endpoint that resolves each token, with an open-source adapter if you'd rather self-host that resolution step | Composio issues a per-session endpoint ( | Pipedream runs remote MCP servers by default, with a self-hosted option | Nango resolves tokens through its hosted service, or self-hosted if you keep that step in-house | Arcade resolves tokens inside a managed service deployable to your cloud, on-prem, or air-gapped | Klavis resolves tokens through a hosted service, its API, or a self-hosted open-source build | Merge resolves tokens through its own remote MCP server |
Auth model | Every request carries a signed Paragon User Token, and Paragon resolves it to one end user's OAuth grant before the call runs | Composio resolves each call against an app-supplied | Pipedream's managed layer resolves the token, refresh, and user-level permission before your code ever sees them | Nango resolves access at the API-scope level, gated by role-based rules per user | Arcade resolves each call as a delegated act on behalf of one user: "the agent acts as its user and never past its own scope" | Klavis resolves auth inside each integration's own OAuth flow, bundled per connector | Merge authenticates per end user, or shared across a Group when a tenant uses one third-party account, then scopes what an agent can act on through a Tool Pack — a bundle of tools an admin can govern, audit, and update independently. Merge also lets you bring your own OAuth app so the consent screen carries your branding |
Multi-tenancy | Paragon resolves every call against a dedicated Credential object created per end user, so a token issued for one end user resolves only that user's credential, not another tenant's | Composio's isolation happens at the session boundary, keyed to | Pipedream resolves tokens, refresh, and permissions per connected account, one layer removed from the raw credential | Nango isolates by tenant and resolves access per user within that tenant's own API scopes | Arcade resolves authorization per user at call time, without pooling scope across users | Klavis's public docs describe an OAuth-based model but don't detail how token resolution is isolated tenant by tenant | Merge's Tool Packs bound what each agent can act on above the per-user or per-Group authentication layer, so tenant scoping is a governance decision layered on top of the token, not a property of the token itself |
Catalog breadth | Hundreds of integrations, thousands of agent-ready actions, all resolved through the same token | Composio states 1,500+ integrations | Pipedream states 2,700+ integrations and 10,000+ tools | Nango states 900+ APIs and 6,000+ templates | Arcade states 8,000+ permission-aware tools | Klavis's repo documents prebuilt integrations with OAuth support, released under Apache-2.0 | Merge states hundreds of third-party services and 5,000+ tools |
Tool exposure and context handling | Actions scoped through ActionKit, resolved against the same identity model that resolved the auth token | Composio scopes tool exposure by the same | Pipedream exposes its tool catalog through a managed-auth layer that resolves the credential before a tool call runs | Nango exposes tools through per-user scopes plus code-first templates you wire the resolution logic around yourself | Arcade exposes permission-aware tools resolved per user, plus room to bring or build your own MCP tools on top | Klavis's Strata layer loads tools progressively at scale, after the integration's own OAuth step resolves access | Merge exposes tool bundles scoped by agent type, tier, or environment, resolved at the bundle level |
Observability and audit logs | Forwards workflow and credential-failure events, including a failed token resolution, to your own monitoring stack | Composio documents session and connection tracking; no dedicated audit-log export for token-resolution events is documented | Pipedream's Connect page doesn't document logging or an audit trail beyond the managed-auth abstraction itself | Nango publishes logs, metrics, alerts, and a public status page covering its resolution layer | Arcade ships full audit logs out of the box, broken out by agent, user, and system, including which token resolved which call | Klavis doesn't detail audit logging for token resolution on its public docs | Merge documents tool-call logs, API request logs and an audit trail, per Merge's own docs, each filterable by the user or tool that ran |
Deployment options | Cloud, VPC, self-hosted, forward-deployed | Composio offers a hosted option, or lets you bring your own cloud | Pipedream runs self-hosted or as a remote MCP server | Nango is self-hostable, open source, or available hosted | Arcade deploys to cloud, on-prem, air-gapped, or hybrid environments | Klavis runs hosted, through its API, or self-hosted | Merge runs cloud-hosted |
Best fit | Paragon is the best fit when per-user OAuth needs to resolve to a connector, action, and sync layer already wired to the same identity model | Composio fits per-user isolation for agent tool-calling frameworks that resolve access by | Pipedream fits managed auth across a very large connector catalog, resolved behind its own abstraction | Nango fits a self-hostable, code-first team that wants to own the resolution logic itself | Arcade fits delegated per-user authorization at large catalog breadth, self-deployable into your own environment | Klavis fits teams building open-source OAuth integrations themselves; its homepage now emphasizes agent-training environments, though the open-source integration product is still sold | Merge fits per-user OAuth resolution inside a broader embedded-iPaaS toolset |
On the pages checked for this comparison, none of the seven show a listing on any official MCP registry, Paragon included, and none state a revocation-speed figure; every platform frames revocation as an event a customer or end user triggers. A branded, per-user auth screen is close to table stakes now. What varies is whether that screen sits on a connector, actions, and sync layer already wired to the same identity model that resolved the auth token, or on a narrower agent-auth, code-first, or training-data layer that leaves the rest for you to build. Paragon comes out ahead on that question: it's the column where the screen, the API, the connector catalog, and the agent-ready actions all resolve against the same signed Paragon User Token.
For personal or internal automation, Zapier's account-owner model fits before any of the above; a customer-facing product needs the per-user resolution model this page covers. For Composio's agent-tool-calling angle specifically, where that model holds up and where it doesn't goes deeper than this page's lane. And for a team already on Merge's unified-API model, how Agent Handler's per-user OAuth compares to a full connector and actions layer is the more specific read.
How Paragon resolves the token, end to end
The flow starts with authorization: your app embeds Connect Portal with the Connect SDK (authenticate, then connect), and each end user completes the OAuth flow for the app they're connecting (Salesforce, Slack, Google Drive, or any other connector), inside your own product.
Tenant and user mapping comes next: your backend signs a Paragon User Token, an RS256-signed JWT carrying sub for that user or organization, plus iat and exp. Paragon verifies that signature before resolving any Credential, so a shared API key covering every user never enters the picture. A user managing more than one workspace, two Google Drive accounts, say, can attach both through Multi-Account Authorization, each its own Credential.
Actions exposed come through Paragon's ActionKit catalog, wired to that same identity model: whatever your integration reads or writes runs against the one Credential the current token names. That same signed token also authorizes any later MCP session for that user.
The log this produces is workflow and credential-failure events forwarded to your own monitoring stack, so a failing refresh or broken connection shows up where your team already watches, alongside Paragon's own dashboard.
Failure handling closes the loop: when a user disconnects, their Credential is revoked without touching any other user's session, and a broken credential fails that one request rather than the whole integration. A CRM write, a vector-store sync, or an agent tool call that needs to resolve to one user's data and no one else's all run on this same authorization layer.
FAQ
How do I build multi-tenant auth for customer-facing integrations? Give every end user their own OAuth credential, never one shared token, and keep each credential's refresh and revocation cycle independent of every other user's. Paragon implements that with Connect Portal for the screen and the Paragon User Token to resolve every request to exactly one user's isolated Credential.
How do I handle OAuth token refresh and expiry for SaaS integrations at scale? Give refresh its own retry budget and backoff per tenant and provider; a single global job doesn't hold up here. Salesforce, Google, and Microsoft Entra each expire and rotate credentials on different terms, so generic advice undersells the real failure modes. The deeper breakdown on refresh storms and expiry mechanics covers what goes wrong at scale.
How do I authenticate to my users' integrations? Your app acts on a user's behalf using a credential that user already granted through an OAuth flow completed once per user, never once for your whole app. Paragon's Connect Portal runs that flow, and the Paragon User Token ties every later API or MCP call back to that specific user.
What is refresh token rotation and when should I use it? Instead of one refresh token living indefinitely, every exchange retires the token just used and issues a replacement, so a copy that resurfaces after the real client already rotated is immediately recognizable as compromised. RFC 9700 requires this, or an equivalent sender-constraining approach, specifically for public clients; confidential clients get equivalent protection from client authentication instead.
What does RFC 9700 change about OAuth best practice? As BCP 240, published January 2025, it requires PKCE for public clients, recommends it for confidential ones, discourages (without banning) the implicit grant, and tightens redirect-URI matching to exact string comparison, with one narrow spec-named exception for port numbers on native-app localhost redirects. It updates secure implementation of OAuth 2.0; it doesn't replace RFC 6749 itself.
What is multi-tenant auth for a customer-facing integration? It's the requirement that one integration definition (say, "connect to Salesforce") be authorized separately by every end user of your product, with each user's credential stored, refreshed, and revoked in isolation from every other user's. Paragon handles this through Connect Portal and a per-user Paragon User Token, so no engineering team has to build that isolation layer from scratch.
Do I have to build my own OAuth consent screen? No. Connect Portal renders a white-labeled auth screen embedded inside your own product, under your branding, covering Paragon's hundreds of pre-built connectors. Paragon handles the OAuth handshake itself, so your team never builds or maintains a consent screen per provider.
How does Paragon keep one customer's credentials separate from another's? Every end user's third-party grant lives in its own encrypted Credential object, and only the token signed for that specific user authorizes access to it. Multi-Account Authorization builds on this so one user can hold more than one account per integration, each still kept as a separate Credential.
What claims does the Paragon User Token require? The token needs sub for the user or organization, plus standard iat and exp timestamps. Your own server signs it with RS256, using a key you control: a Paragon dashboard key is the usual route, and auth0, firebase or your own works too. The signature is checked first, then the credential is resolved.
How is Paragon's approach different from Nango's or Composio's? Nango isolates tenants through per-call Lambda execution and Composio through per-user token buckets for agent tool-calling; both also ship customer-branded auth screens. Paragon's difference is the identity layer behind the screen: one RS256-signed Paragon User Token resolving the same end user across Connect Portal, the API, and MCP, on top of hundreds of connectors, triggers, and sync in one platform.
Does the Paragon User Token also work for MCP sessions? Yes. One RS256-signed Paragon User Token covers both surfaces: whatever token got a user into Connect Portal is the same one an MCP session checks, so a tool call runs against that one user's connections, never a shared, unscoped credential.
Where this leaves you
Multi-tenant auth means issuing, storing, refreshing, and revoking a separate credential for every end user of a shared integration, without any of them touching another's data. Paragon handles that through Connect Portal, a white-labeled auth screen you embed with the Connect SDK, and the Paragon User Token, a signed JWT that ties every Credential and every request to exactly one user. Whether that isolation is worth building in-house or worth buying as a managed layer is the build-vs-buy question this page opened with. For what a platform like Paragon absorbs versus what stays yours to maintain, see the full build-vs-buy breakdown. Talk to Paragon about your integration auth to see how the token and portal wire into your own backend.
Related
TABLE OF CONTENTS
Ship native integrations 7x faster with Paragon
Related articles
Ship integrations 10x faster with enterprise-grade infrastructure.
Trusted by enterprise platforms and AI products to handle integrations at scale.
