Business to Business (B2B)
Descope is built for B2B apps where each customer is its own organization. You integrate once; every customer becomes a tenant with its own users, SSO, roles, branding, and admin self-service.
To see the model in a running app, try the B2B React sample app (Gibber).
What You Get Per Customer
One Descope project can serve many customers. Each customer is a tenant with its own identity provider, users, roles, SCIM, and styling, while your app keeps a single integration.
One integration into Descope, and each customer is its own tenant with its own IdP. Their IT admins can configure SSO themselves through the SSO Setup Suite.
How Multi-tenancy Works
Users live at the project level. A user can belong to zero, one, or many tenants, and roles are scoped per tenant. The same person can be an Admin in one customer org and a Member in another, without a second identity.
Alice belongs to Acme and Globex with different roles in each. Bob is only in Acme. Carol has an identity in the project but isn't in a tenant yet.
- Identity is project-scoped. Login ID, credentials, and MFA are shared across tenants by default. If the same email must be a separate account in each tenant, enable Tenant User Isolation.
- Authorization is tenant-scoped. Roles and permissions are assigned per tenant and show up that way in the JWT.
- Your app enforces the JWT. Descope authenticates the user and puts tenant membership and roles in the token. Your backend decides what that allows.
How B2B differs from B2C
Login and sessions look familiar, but selling to companies changes the identity model:
- Orgs are the unit of identity. Users act on behalf of a tenant. Your backend needs to answer “which organization is this request for?” as reliably as “who is this user?”
- Enterprise SSO is expected. Customers authenticate through Okta, Entra ID, Google Workspace, and similar IdPs. You usually need SSO per tenant, sometimes multiple IdPs on one tenant, and self-service setup so their IT isn’t opening tickets with you.
- Access control is contextual. Roles differ per tenant, often driven by IdP group mapping. When static roles aren’t enough, use FGA (ReBAC / ABAC).
- Lifecycle and compliance bar is higher. Plan for JIT on SSO login, SCIM for hire/fire, MFA where required, and audit trails for sign-ins and admin changes.
Common B2B use cases
Pick the rows that match what you're building:
| Use case | What you do with Descope |
|---|---|
| Enterprise customer with their own IdP | Create a tenant, connect SAML or OIDC (SSO), optionally let their IT admin finish setup in the SSO Setup Suite. |
| Self-serve customer onboarding | Create tenants from Flows, the Console, or Management SDKs / APIs. Invite users or provision via SSO/SCIM. Sync CRM or billing with connectors in the onboarding flow if you need it. |
| Route users by email domain (or enforce SSO) | Associate domains with the tenant, and use Flow conditions to send SSO-enabled users to the right IdP (Enforcing SSO). |
| Customer admins manage their own org | Embed the Admin Portal (or admin widgets) so tenant admins manage users, SSO, access keys, and audit logs without your support team. |
| Directory sync from the customer's IdP | Turn on SCIM per tenant so users and groups stay in sync. |
| Roles from IdP groups | Map groups and attributes on SSO login with SSO mapping so access follows the customer's org chart. |
| Different auth rules per customer | Override passwords, OTP, Magic Link, MFA, session policy, and more at the tenant level. |
| Customer-specific login look and feel | Apply tenant-level styles so each org sees its own branding in Flows. |
| Departments or regions under one customer | Model hierarchy with sub-tenants. |
| Same person in multiple customer orgs | Keep one project identity and assign them to multiple tenants with different roles (see the diagram above). |
| Fine-grained permissions beyond roles | Use FGA (ReBAC / ABAC) when access depends on ownership, membership, or attributes, not only role names. |
| Add SSO without replacing your auth | Use Descope only for the SSO handshake while you keep your own sessions. Start with Getting Started with SSO. |
Product Map
Deeper how-to pages, grouped by topic:
Tenants and Users
Create orgs, attach users, and scope roles per tenant:
| Topic | Docs |
|---|---|
| Create and manage tenants | Tenant management, Configuring a tenant |
| Sub-tenants and hierarchy | Sub-tenants |
| Users, invites, custom attributes | User management |
| Roles and permissions (including Tenant Admin) | RBAC, B2B RBAC example |
| Fine-grained authorization (ReBAC / ABAC) | Authorization / FGA |
| Tenants in Flows | Handling tenants in Flows |
SSO and Federation
Wire each customer's IdP, map groups, and provision on login:
| Topic | Docs |
|---|---|
| SSO overview (SAML / OIDC, IdP vs SP) | SSO |
| Quickstart (configure + code) | Getting Started with SSO |
| Customer self-service SSO setup | SSO Setup Suite |
| Configure SSO on a tenant (Console / SDK) | Tenant SSO |
| Multiple IdPs on one tenant | Multiple SSO providers |
| Domain routing and SSO enforcement | SSO domains, Enforcing SSO in Flows |
| JIT provisioning and attribute / group mapping | JIT, SSO mapping |
| Test without a real IdP | Mock SAML |
| Go-live checklist | SSO launch checklist |
Admin Self-service and Provisioning
Hand day-to-day identity work to the customer's admins, and keep directories in sync:
| Topic | Docs |
|---|---|
| Admin Portal for tenant admins | Admin Portal |
| Embed individual admin widgets (users, roles, access keys, audit) | Admin widgets |
| SCIM provisioning | SCIM |
| Audit trails and streaming | Audit |
Branding, Sessions, and Auth Methods
Per-tenant login UX and security policy:
| Topic | Docs |
|---|---|
| Tenant-level Flow styling | Styles |
| Per-tenant auth, MFA, and session settings | Configuring a tenant |
| MFA and step-up | MFA |
| Project-level SSO settings | SSO settings |
| Connectors in onboarding Flows | Connectors |
Sub-tenants
When one customer needs nested orgs (regions, business units, franchises), use sub-tenants. Inheritance of users and roles from the parent is configurable when you create the child.
A tenant can have multiple sub-tenants, and sub-tenants can nest further, but each sub-tenant has exactly one parent. Inheritance flows downward only: a sub-tenant can inherit users and roles from its parent (see Role Inheritance), and membership on a sub-tenant never grants access back up to the parent.
Where to Start
- Create a tenant in the Console or via the Management SDK.
- Decide how users join: invites, self-sign-up into a tenant, SSO, or SCIM.
- If customers bring their own IdP, plan for the SSO Setup Suite and Admin Portal so their admins can self-serve.
- Assign roles per tenant and validate the tenant claims in your session JWT.
For a longer product overview, see the B2B Authentication blog post.