Enterprise SSO

Enterprise SSO lets each B2B customer authenticate through their own identity provider (IdP) like Okta, Entra ID, OneLogin, Google Workspace, and others.

SSOJet acts as the federation layer so your team can focus on tenant routing, account linking, sessions, and authorization.

TL;DR

• Configure SSO per tenant, not globally.
• Choose protocol by customer requirement: SAML or OIDC.
• Start with SP-initiated flow for most products.
• Validate routing, linking, and failure paths before production.
• Keep break-glass login and rollback controls for each tenant rollout.

Overview

SSOJet supports the most common enterprise protocols:

• SAML 2.0 for classic enterprise federation
• OpenID Connect (OIDC) for OAuth-based federation
• Directory Sync (SCIM) for user and group provisioning

Your app integrates once with SSOJet, and each customer’s IdP is configured as a tenant-scoped connection.

When To Use This

• You sell B2B software and enterprise customers require SSO for compliance and centralized access.
• You want to avoid building and operating per-customer SAML/OIDC integrations.
• You need both SP-initiated and IdP-initiated login support.

What SSOJet Handles vs What Your App Handles

SSOJet HandlesProtocol details (SAML/OIDC), metadata/discovery, signature/token validation, connection lifecycle, and federation flow reliability.

Your App HandlesTenant selection, account linking, session issuance, authorization (RBAC), and post-login routing.

Key Decision Early

Decide early how you map an incoming enterprise identity to an application user and tenant. Most SSO production issues are account-linking and tenant-routing problems, not protocol problems.

Recommended Implementation Sequence

Choose Protocol Per Tenant

• Use SAML for traditional enterprise IdPs and certificate-driven federation.
• Use OIDC for modern OAuth/OIDC-first customer environments.

Related docs:

• SAML Setup
• OIDC Setup

Configure Connection Details

Complete metadata/discovery exchange and configure required claims and mappings.

Related docs:

• SAML Configuration
• OIDC Configuration
• Attribute Mapping

Validate Login Flows

Test both flow types in a sandbox tenant before production onboarding:

• SP-Initiated SSO
• IdP-Initiated SSO

Gate Production Rollout

Validate protocol behavior, mapping, and recovery paths before enabling production tenant traffic.

• Connection Testing
• Security Checklist

Getting Started In Dashboard

SSOJet’s hosted sign-in experience can route users to SSO automatically when their email domain (or tenant selection) maps to an active SSO connection.

Enable Enterprise SSO In Sign-In Experience

1. Open the SSOJet dashboard.
2. Go to Sign-in Experience.
3. Enable Enterprise Single Sign-On.

Supported Protocols

SAML (SAML 2.0)

SAML is the most common enterprise standard. It uses signed XML assertions and certificate-based verification.

• Best for: large enterprises, traditional IdPs, and long-lived stable configurations
• You configure: ACS URL, Entity ID/Audience, and IdP metadata/certificates

SAML Flows

SP-initiated: user starts in your app and is redirected to the IdP.

IdP-initiated: user starts in the IdP portal and launches your app tile.

OpenID Connect (OIDC)

OIDC is an OAuth 2.0 based protocol that uses discovery and signed JWTs.

• Best for: modern IdPs and API-first environments
• You configure: issuer/discovery URL, client ID/secret, and redirect URI

Avoid Implicit Flow For New Builds

For SPAs, prefer Authorization Code Flow with PKCE. Implicit flow is legacy and harder to secure.

Directory Sync (SCIM)

Directory Sync provisions users and groups from the customer’s directory into your app (via SSOJet), enabling automated onboarding and deprovisioning.

Multiple SSO Connections Per Tenant

A single tenant is not limited to one identity provider. SSOJet lets you attach multiple enterprise SSO connections to the same tenant and mix protocols freely. One tenant can run a SAML connection and an OIDC connection side by side, each active and independently configured.

This is essential for real B2B deployments, where a single enterprise customer rarely maps cleanly to a single IdP: acquisitions, subsidiaries, contractor populations, and in-flight IdP migrations all create the need for more than one identity source under the same logical customer.

In the example above, one tenant has two active connections — a CustomOIDC (OpenID Connect) connection and an Okta (SAML 2.0) connection — alongside a separate SCIM directory for provisioning. Use Add SSO Connection to attach more.

Why Multiple Connections

Mergers & AcquisitionsA customer acquires another company that keeps its own Okta/Entra tenant. Both employee populations sign in under one customer tenant, each through their existing IdP — no forced directory migration.

Subsidiaries & Business UnitsA parent organization with several divisions, each running its own IdP, maps all of them to one tenant so they appear as a single customer in your product.

IdP MigrationRun the old and new IdP in parallel during a cutover. Move users in waves and remove the legacy connection once migration completes — with zero downtime.

Workforce vs ContractorsFull-time employees authenticate through the corporate IdP while contractors or partners use a separate connection, often with different attribute mappings or MFA policy.

Regional DirectoriesEU and US user bases live in separate regional directories for data-residency reasons but belong to the same commercial account.

Resilience & Break-GlassA secondary connection provides a fallback path if the primary IdP has an outage or a misconfiguration, keeping enterprise users from being locked out.

How Routing Works With Multiple Connections

When a tenant has more than one connection, SSOJet picks the correct one at sign-in time. Plan your routing strategy explicitly:

SP-Initiated (your app starts the flow)

Pass a tenant identifier plus an optional email/domain hint. SSOJet resolves the connection whose mapped domain matches the user’s email. Map each connection to distinct domains so routing is unambiguous — for example @acme.com → Okta, @subsidiary.com → CustomOIDC.

IdP-Initiated (the IdP starts the flow)

Each connection has its own ACS URL / callback endpoint, so an assertion launched from a given IdP tile resolves directly to the connection it was configured for. No domain disambiguation is needed.

Ambiguous Or Overlapping Domains

If two connections in the same tenant could match the same user, present a connection picker in your sign-in UI or route on an explicit connection parameter. Avoid leaving overlap to chance — deterministic routing prevents users from landing on the wrong IdP.

When an organization has more than one SSO connection and the tenant alone is ambiguous, pass the connection’s ID directly in the OIDC authorization request to open one specific IdP login — see Target a Specific IdP With connection_id.

One Identity, Many Sources

Regardless of which connection a user comes through, your app still receives a single normalized identity result. Use Attribute Mapping and JIT Provisioning so users from different connections resolve to consistent application users and roles.

Example: Mixed-Protocol Tenant

A customer “Acme Corp” has acquired “Globex”. You model both under one tenant:

Connection	Protocol	Domain(s)	Purpose
Acme-Okta	SAML 2.0	acme.com	Existing Acme employees
Globex-OIDC	OpenID Connect	globex.com	Acquired Globex employees
Inc-Okta	SCIM (Directory Sync)	—	Existing inc employees

Acme employees are redirected to Okta via SAML; Globex employees are redirected to the OIDC IdP — all within the same tenant, the same billing account, and the same in-app experience.

Each Connection Is Counted And Billed

Every enabled enterprise connection on a tenant counts separately. A tenant with Okta + CustomOIDC active counts as two connections. See SSO Connection Counting for the full model and how to keep inventory clean.

Operational Guidance

• Name connections clearly (e.g. Acme-Okta-Prod, Globex-OIDC) so operators can tell them apart at a glance.
• Keep domain mappings non-overlapping to guarantee deterministic SP-initiated routing.
• Test each connection independently in the Test SSO panel before enabling it for production traffic.
• Retire connections you no longer need — disable first to verify no users depend on it, then delete to stop counting it.
• Model unrelated identity populations as separate tenants when it keeps inventory and billing cleaner than stacking many connections on one tenant.

Testing With A Sandbox IdP

Before onboarding a real customer IdP, validate the full round-trip in a safe environment.

Open The Test Tenant

In the SSOJet dashboard, open Tenants and select the pre-configured test tenant (or create a dedicated sandbox tenant).

Use The Test SSO Panel

Click Test SSO to open the right-side panel with SP Initiated and IdP Initiated tabs.

Validate Both Flow Types

Verify that:

• Users land in the correct tenant
• The identity maps to the right application user
• Your app issues a session and routes correctly after login

SP-initiated testYour app starts the flow: sign-in, redirect to IdP, callback, session.IdP-initiated testThe IdP starts the flow: launch from the IdP portal and deep-link into your app.

Setting Up Real Customer Connections

Once sandbox flow works end-to-end, onboard a real customer by creating a tenant and generating the IT Admin Portal link (self-serve wizard for their IdP).

Create Or Select The Customer Tenant

Tenants represent your B2B customers.

Generate The IT Admin Portal Link

Use Generate URL in the self-service configuration area.

Follow Provider-Specific Setup Wizard

Customer IT admins get exact setup steps for Okta, Entra ID, OneLogin, and more.

For full setup docs, follow:

1. SAML Setup
2. OIDC Setup
3. Connection Testing

Core Enterprise SSO Docs

SP-Initiated SSOYour app starts login and controls tenant routing.IdP-Initiated SSOCustomer IdP starts login from their portal tile.SAML SetupEnd-to-end SAML onboarding flow for customer tenants.OIDC SetupEnd-to-end OIDC onboarding flow for customer tenants.SSO IntegrationsProvider-specific guides for Okta, Entra ID, Google Workspace, OneLogin, and more.Connection TestingTest tenant routing, identity mapping, and callback behavior.

Best Practices

Start With A Pilot Group

Onboard one tenant (or one business unit) first. Watch success/failure rates and collect IdP-specific edge cases before broad rollout.

Test In Staging First

Always validate metadata, redirect URIs, and attribute mapping in staging. A single wrong URL can lock an enterprise tenant out.

Frequently Asked Questions

Does SSOJet Support IdP-Initiated SAML?

Yes. SSOJet supports IdP-initiated SAML, including deep-linking into your app after IdP tile launch.

Can Different Tenants Use Different Protocols?

Yes. Tenant A can use SAML while Tenant B uses OIDC. Your application still receives a normalized identity result through SSOJet.

Can A Single Tenant Have Multiple SSO Connections?

Yes. A tenant supports multiple connections, and you can mix protocols — for example a SAML connection and an OIDC connection active at the same time. This is common for acquisitions, subsidiaries, and IdP migrations. See Multiple SSO Connections Per Tenant.

How Does Routing Work When A Tenant Has Several Connections?

For SP-initiated login, SSOJet matches the user’s email domain to the connection mapped to that domain. For IdP-initiated login, each connection has its own callback endpoint, so the originating IdP resolves directly. Keep domain mappings non-overlapping to ensure deterministic routing.

Should We Support Both SP-Initiated and IdP-Initiated?

Yes. Most products default to SP-initiated, but enterprise customers commonly require IdP-initiated support too.

How Does SSOJet Know Which IdP To Route To?

Your app provides a tenant identifier (organization/tenant ID) or an email hint. SSOJet resolves the connection mapped to that tenant/domain and routes to the correct IdP.

Where Do We Put Provider-Specific Setup Guides?

Use SSO Integrations, which is grouped under Enterprise SSO.