How to handle multi-tenant authentication for a B2B SaaS, with white-label login for every customer

Multi-tenant authentication for a B2B SaaS is handled by modelling each corporate customer as an isolated tenant, with its own user base, its own security policies, its own SSO federation to the customer's identity provider and its own branding on the login pages. Six decisions matter, they are taken before writing code, and the most expensive one to change later is the first: whether a user is a single platform-wide entity belonging to several tenants, or whether each tenant has a separate user base.

Step 1 — The identity model: the irreversible decision

The concrete question is this: if Jane works for customer A and is also invited by customer B with the same email address, is she one person or two?

The choice should be made looking at the sales model, not the data model: if you sell to large companies bringing their own employees, a separate base per tenant is almost always right; if your product is used by agencies and consultants working for several clients, rigid separation becomes a recurring complaint by month three.

Step 2 — How the tenant is resolved at login

Before authenticating you need to know in which context you are authenticating: it decides which branding to show, which policy to apply and which identity provider to route to.

In practice mature SaaS products combine two: subdomain or custom domain for branding, and home realm discovery on the email domain to route federated users to the correct IdP.

Step 3 — Per-customer federated SSO

The first enterprise customer signing a meaningful contract will ask for SSO with their own Entra ID. The second uses Google Workspace. The third has Okta and a SAML 2.0 requirement. If federation is configured globally rather than per tenant, every new customer becomes a development project.

• Identity provider configuration (client ID, secret or certificate, metadata, claim mapping) must belong to the tenant.
• Group → role mapping differs per customer: 'GRP-ADMIN' at Acme and 'admins@beta.com' at Beta must be able to point to the same application role.
• Federated users and local-credential users must coexist in the same tenant: almost every customer has at least one external consultant outside their directory.
• Deprovisioning follows the customer directory: when their IdP disables the user, access to your SaaS stops without a ticket to your support.

The full federation procedure for Entra ID and Google Workspace, with endpoints, claims and typical errors, is in the dedicated SAML 2.0 and OIDC SSO guide.

Step 4 — White-label: what must really be customisable

"White-label" used as a synonym for "you can upload a logo" is the most frequent cause of renegotiation with an enterprise customer. The list of what the end user sees, and which must therefore be able to belong to the customer, is longer than it looks.

In LoginMaster no vendor reference appears in the production user experience, and customisation extends to email templates, domain and identity management pages, with different templates per language and user type. Details on white-label authentication.

Step 5 — Isolation: logical or cryptographic

Nearly every platform claims tenant isolation. The question that discriminates is: is isolation guaranteed by an application check — a WHERE tenant_id = ? clause and a claim in the token — or by a cryptographic property?

The difference shows in one scenario only, but it is the one that counts: a bug in a query, an unverified claim, a manipulable parameter. With application-level isolation that bug is a cross-customer data breach. With cryptographic isolation, validation fails structurally because the token is not signed with that tenant's keys.

POST /v1/auth/verify HTTP/1.1
Host: api.loginmaster.it
X-Project-Key: pk_live_••••••••
Content-Type: application/json

{ "token": "lm2f.eyJhbGciOiJFZERTQS..." }

HTTP/1.1 200 OK
{
  "valid": true,
  "subject": "sub_9f2a7c",
  "tenant": "https://acme.example.com",
  "signatures": { "tenant": "verified", "cloud": "verified" }
}

Every tenant has its own cryptographic identity and every project its own key: a token issued for tenant Acme, presented in the context of tenant Beta, does not fail a check — it fails signature verification. It is the same property that makes it sustainable to host mutually competing customers on the same platform, which is the norm in a vertical SaaS.

Step 6 — Onboarding a new customer via API

If creating a tenant requires a person, the marginal cost of a customer never goes down. Onboarding must be a sequence of API calls your back-office or a self-service flow can run.

1. 1Create the tenant and set baseline policies (session lifetime, password requirements, allowed second-factor types, authorised email domains).
2. 2Register the projects: web application, mobile app, optional customer admin panel, each with its own 2FA policy.
3. 3Apply branding: logo, palette, email templates, default language.
4. 4Configure federation, if the customer brings their own identity provider.
5. 5Provision the initial users and subscribe to webhooks to keep application state in sync.

POST /v1/projects/prj_12ab/subjects HTTP/1.1
Host: api.loginmaster.it
Authorization: Bearer ak_live_••••••••
Content-Type: application/json

{
  "type": "user",
  "externalId": "acme-4821",
  "roles": ["member"]
}

The full lifecycle, including role change and deactivation, is in User provisioning and lifecycle via REST API and SDK.

Build, self-host or platform: the comparison

There are four real options for a B2B SaaS. None is wrong in the absolute: what changes is when the cost shows up and who pays it.

The pricing point, which in B2B is architectural

In a B2B SaaS you do not decide the number of end users: your customer does. An authentication model priced per active user means a contract won with a 30,000-employee customer carries a variable cost that erodes the margin of that contract exactly when it should improve it. LoginMaster bills per tenant and per project, with users always unlimited and included: authentication cost stays predictable while your customers grow. The model is described on pricing.

Do you need CIAM or IAM?

Anyone evaluating platforms for a multi-tenant B2B SaaS meets both acronyms. IAM in the strict sense governs workforce identities: employees, corporate SSO, lifecycle, internal access. CIAM governs customer identities: self-service registration, white-label login, far higher volumes and attention to experience. A B2B SaaS needs both, because its users are employees of customer companies: identities with CIAM requirements for scale and branding, but governed by the customer's workforce policies.

That is why the same platform must cover both worlds in the same tenant, with distinct policies and branding per user type: the CIAM and IAM for B2B SaaS pages cover the two sides.

Where this guide comes from

LoginMaster is the IAM platform of CDBKR S.r.l., an Italian company providing authentication infrastructure to software houses and MSPs that resell their product to corporate customers. The tenant concept, the cryptographic isolation and the white-label described here are the architectural constraints the product is built on, not features added later: Security covers the detail, the case studies show a real adoption and the partner programme the model for resellers. To discuss your own scenario: contact us.