Multi-tenant auth for customer-facing integrations

Paragon handles multi-tenant auth for customer-facing integrations with Connect Portal, a white-labeled auth screen embedded directly in your app, paired with the Paragon User Token, a signed, per-user JWT your own server issues. Every credential the flow collects is stored as its own encrypted Credential, Paragon is SOC 2 Type II, GDPR, and HIPAA compliant, and the same token model already authorizes integration access for products like Zendesk, Postman, and CrewAI. Every customer who signs up for your product wants to connect their own Salesforce, Slack, or Google Drive account to it, and none of them can be allowed anywhere near another customer's tokens. Multiply that by a few hundred accounts: each one needs its own OAuth flow started, its own credential issued, stored, refreshed on its own schedule, and revoked the moment that customer disconnects, without a single token ever leaking sideways into someone else's session.

How Paragon handles multi-tenant auth for customer-facing integrations

Paragon is the pick for teams that need a ready-made, white-labeled auth screen their own customers can use across Paragon's 130+ pre-built connectors, backed by a documented per-user token their backend can verify, rather than a bare API they'd have to wrap in a UI themselves. Connect Portal handles the OAuth screen and branding; the Paragon User Token, an RS256-signed JWT your server issues with sub, iat, exp, and aud claims, ties each session to one specific end user; and every credential that comes back from that flow is stored as an isolated Credential object, encrypted in transit and at rest, that only resolves for the user it belongs to. Together, those three pieces are a multi-tenant auth layer built to scale to thousands of end users without a shared credential ever crossing accounts.

What multi-tenant auth actually requires

A single-tenant OAuth integration is comparatively simple: one app, one set of credentials, one token to refresh. A customer-facing integration multiplies that by every end user of your product. You're defining the integration once (say, "connect to Salesforce") but authorizing it thousands of times, once per customer, and every authorization has to stay fully separated from the others. A bug in your token storage, refresh logic, or session-to-credential mapping doesn't produce a broken feature. It produces one customer's data showing up in another customer's account.

That requirement breaks into a few concrete pieces: issuing a distinct credential per end user rather than one shared app-level token, refreshing each credential on its own schedule without touching anyone else's, mapping an incoming request to exactly the right user's credential before any API call goes out, and revoking a single user's access cleanly on disconnect or churn, without disturbing the rest. Get any one wrong at scale and you've built a data-isolation bug into your own product.

How Paragon isolates credentials per end user

Every time a user completes the auth flow, Paragon stores their third-party credential as its own Credential object, distinct from every other user's, encrypted both in transit and at rest. That object is what Paragon resolves against when your app makes a request on that user's behalf, and it's what gets revoked or re-authorized without touching any other user's connection.

Users aren't limited to one account per integration, either. Multi-Account Authorization lets a single end user attach more than one account for the same integration, two separate Google Drive accounts, for instance, each stored as its own Credential with its own ID. That matters for a customer who manages more than one third-party workspace and needs your product to address a specific one, not just "whatever they connected first."

The Paragon User Token, explained

The mechanism that ties a request to the right Credential is the Paragon User Token: an RS256-signed JWT that your application server signs, not Paragon. You generate a private signing key from the Paragon dashboard under Settings, sign a token containing sub (your user's or organization's ID), iat, and exp, plus an aud claim formatted as useparagon.com/{project-id}, and Paragon verifies that signature against the matching public key before it will resolve any Credential for that session. Your backend never hands Paragon a shared API key that covers every user; it hands Paragon a token scoped to exactly one.

The Connect SDK's .authenticate() method is called at the start of your app's session so the token stays current while the user is active, and the same token authorizes both the Connect Portal auth screen and any subsequent API or MCP session tied to that user. One signed claim, reused everywhere Paragon needs to know whose data it's touching, replaces separate credential stores for a UI flow, a REST call, and an agent session, including agents built to integrate external data on a user's behalf.

The embedded auth experience (Connect Portal)

Most teams don't want to design and maintain their own OAuth consent screens for every third-party app they support, and they don't want customers redirected to a generic, unbranded authorization page either. Connect Portal solves both with a single SDK call: it renders a white-labeled auth experience under your own domain, and it's the same UI your customers use whether they're connecting Salesforce, Slack, or any of Paragon's 130+ pre-built connectors. Full removal of Paragon branding is a paid-plan feature, but the embed itself, with your customer completing the flow inside your product instead of a third-party page, is the default.

That single embed point is also where the isolation model above becomes visible to your users: each person who runs through Connect Portal gets their own Credential, tied to their own Paragon User Token, and can disconnect or reconnect their account without any visibility into or effect on anyone else's.

How Paragon fits

Two rhythms make up this flow: what happens once per end user, and what happens on every request after that.

Once, when a user connects: your app embeds Connect Portal with a single SDK call, the user completes the OAuth flow for the third-party app, and Paragon stores that authorization as a per-user Credential, encrypted at rest.

On every request after that: your app passes a signed Paragon User Token naming which end user it's acting on behalf of, Paragon resolves that specific user's Credential and never a different one, and refresh and revocation happen on that Credential without your backend tracking expiry windows or storage itself.

What your integration does with that access, which CRM records it reads or writes, or what it syncs into your own pipeline, is a separate layer on top of this one: see connecting your SaaS to Salesforce and HubSpot for the CRM case and syncing customer data into a vector database for ingestion. The same identity model underlies agent-facing integration setups, where a tool call needs to resolve to one user's data and no one else's. This article stops at authorization: the right user authenticated, isolated, and resolvable, before any action or sync runs.