B2B SaaS access quickstart
Set up SecureAuth Connect for a B2B SaaS application where each business customer gets its own identity provider, branding, policies, and delegated administration. SecureAuth models each customer as an Organization with scoped configuration, running against one shared tenant or a dedicated tenant per customer.
What is B2B identity?
B2B identity differs from consumer or workforce Identity and Access Management (IAM) in four ways:
-
The customer is an organization. Users belong to a tenant, a company, a franchise, or a workspace. Authorization decisions usually need the organization context, not just the user identity.
-
Every customer brings their own IdP. Enterprise buyers expect SAML or OIDC federation to their Okta, Entra ID, Ping, or SecureAuth instance. You don't own their user directory.
-
Delegated administration is required. Customer admins add, remove, and audit their own users. Your support team cannot be in the loop for routine changes.
-
Per-customer branding and policies. Each customer expects their login page, MFA rules, and session policies to match their internal standards.
SecureAuth Connect supports this with Organizations (logical customer boundaries inside a tenant), Workspaces (stronger config isolation when you need it), Delegated Administration (scoped roles for customer self-service), Federation per organization, and vanity domains like login.customer-name.com.
How Organizations map to your customers
Pick your isolation model
The isolation decision comes down to what gets shared across customers and what each customer owns. SecureAuth gives you three tiers, all of which run inside one SecureAuth tenant except the strictest.
| Model | When to use | SecureAuth design |
|---|---|---|
| Shared application (default) | Standard SaaS: SMB, mid-market, self-service sign-up, one product surface for everyone | One tenant, one OIDC client shared by all Organizations. Tokens carry org_id so the app distinguishes customers at runtime. |
| Per-organization application | Enterprise customers who want their own app credentials, their own IdP, their own branding, their own admins, but you still run one SaaS platform | One tenant, one Organization per customer, one dedicated application (OIDC client) per Organization. All policies and branding scope to the Org. |
| Dedicated tenant | Rare: strict data residency, customer contract mandates a separate SecureAuth instance, regulated workloads requiring independent keys and independent upgrade cadence | A separate SecureAuth tenant per customer. Operationally heavier. |
Most teams start with shared application, then move specific enterprise customers to per-organization application as their contracts or branding requirements grow. Dedicated tenants are reserved for the handful of cases where nothing inside a shared tenant will satisfy compliance.
Side-by-side
The per-organization model gives each customer a dedicated environment without running multiple SecureAuth tenants. Keys, quotas, policies, and branding are all scoped at the Organization level.
1. Create your tenant and workspace
In the admin console, create a new workspace and select Partners B2B Integration. This workspace is pre-configured for B2B SaaS applications with organization-aware token claims, OIDC with PKCE, and refresh token rotation.
2. Define an Organization per customer
Each business customer becomes an Organization inside your workspace. The Organization scopes users, admins, federation, and policies.
- Organizations overview
- Create organizations and sub-organizations
- Building B2B SaaS with Organizations
3. Connect each customer's Identity Provider
Most B2B customers will federate with their own IdP. SecureAuth supports SAML and OIDC per Organization, with just-in-time user provisioning on first login.
- Integrate SSO Identity Providers
- For customers without an IdP, use a shared Identity Pool scoped to the Organization.
4. Apply per-organization branding
Each customer gets their own login experience.
- Branding overview for logos, colors, and fonts.
- Vanity domains so login runs on
login.customer-name.com. - Customize templates for email, SMS, and voice notifications (invitations, password reset, MFA).
5. Enable Delegated Administration
Let customer admins manage their own users, roles, and policies without touching your support team.
- Delegated administration
- Delegated admin portal for the end-user-facing console.
6. Shape tokens with organization context
Your application authorizes based on who the user is and which organization they belong to. Add organization metadata to tokens so downstream services can enforce access based on organization membership.
- Manage token claims to inject
organization_id, roles, and custom attributes. - Apply authorization policies to validate user + org attributes before issuing tokens.
7. Connect your application
Register your SaaS app as an OIDC client.
- Server-side web application
- Single-page application (SPA)
- Use the OIDC quickstart to set up the authorization code flow with PKCE.
Next steps
- Machine-to-machine clients for service-to-service API calls inside each customer's environment.
- Sample apps for React, Node.js, and mobile starters you can fork.
- Open Finance quickstarts if your B2B platform handles regulated financial data.