Enterprise SSO

What is enterprise SSO?

Enterprise SSO lets your customers sign in to the portal using the same credentials and policies as your other internal or customer-facing applications. Users authenticate with your identity provider (IdP); acts as the service provider (SP) and trusts the SAML 2.0 assertion from your IdP.

This is appropriate when:

• Your organization mandates a single corporate IdP
• You need centralized access control, MFA, or conditional access policies
• Customers should not receive separate passwords or magic links

Supported identity providers

supports SAML 2.0 with common enterprise IdPs, including:

• Okta, Auth0
• Microsoft Entra (Azure AD), Active Directory federation
• Google Workspace
• PingIdentity, OneLogin
• Other SAML 2.0–compliant providers (including self-hosted or on-prem IdPs)

If your IdP is not listed, contact support — compatibility is determined by standards-compliant SAML metadata and assertion content, not a fixed vendor list.

Sign-in flows

Customers can reach the portal through either flow once SAML is configured:

can advise on the best pattern for your IdP during setup. Some IdPs expose only metadata URLs; others require a downloaded metadata XML file — both are supported.

User matching and accounts

For SSO to succeed, the assertion must identify the customer in a way can match to an onboarded customer:

• An email address must be present in the SAML assertion (as a named attribute or as a NameID in email format). Assertions without a usable email are rejected.
• The email should match the contact email used when the customer was onboarded via the Partner API.
• Automatic linking between SSO and other sign-in methods (such as magic link) for the same email is not performed. Plan for one primary sign-in path per customer, or coordinate with if you need to migrate users.

can work with you on attribute mapping when your IdP uses non-standard claim names (for example mail instead of email).

Sessions and logout

• After a successful SAML sign-in, the customer receives a portal session (access and refresh tokens). Access tokens are typically valid for one hour; the portal refreshes the session while the customer is active.
• Your IdP may impose additional session limits (maximum session duration, idle timeout, or step-up MFA). Those policies apply at your IdP; honours forced re-authentication when reflected in the assertion or IdP session state.
• Single logout (SLO) from the portal back to your IdP is not supported. To require regular re-authentication, configure session timeouts or conditional access at your IdP, and direct customers to sign out of the portal when needed.

What configures

Every enterprise SSO deployment is different: IdP vendor, attribute names, domain restrictions, MFA requirements, and staging vs production cutover all affect the integration.

does not publish a self-service IdP configuration guide because these details vary between partners. Instead, we configure SSO per partner when you are ready to go live.

During setup, will share service provider (SP) details for your IdP administrator, such as:

• Entity ID and metadata URL (or metadata XML) for the auth endpoint
• Assertion Consumer Service (ACS) URL where your IdP posts SAML responses
• Expected NameID format (email-based identifier)
• Redirect URLs allowed after sign-in

You provide identity provider (IdP) details, such as SAML metadata (URL or XML file), email domains used for routing, and any required attribute mappings.

What to provide when contacting

• IdP vendor and SAML metadata (URL or XML file)
• Email domains or attribute rules used to identify your customers (for example company.com)
• Attribute mapping notes if your IdP does not send a standard email claim
• Required redirect URLs after sign-in (staging and production)
• Whether you need SP-initiated, IdP-initiated, or both
• Target go-live date and environments (staging vs production)

Contact your account team or support to start an enterprise SSO engagement.

SAML terminology

Troubleshooting

Ask your IdP administrator to confirm that the user’s email is released in the SAML assertion (common attribute names include email, mail, or WS-Federation-style email claims).

Alternative: magic link

If you do not need corporate IdP integration, you can sign customers in programmatically with the magic link API. This is self-serve via the Partner API and does not require to configure SAML.