Skip to main content
Single sign-on lets your team sign in to OpenCX with the credentials they already use everywhere else. Instead of a per-user email and password, members authenticate against your identity provider (IdP), Microsoft Entra ID, Okta, Google Workspace, or any SAML 2.0 / OIDC provider, and OpenCX trusts the identity your IdP asserts.
SSO is available on Enterprise plans and is enabled by OpenCX during onboarding; it isn’t self-serve from the dashboard yet. Contact [email protected] or your OpenCX contact to open a connection. Once the connection exists, you configure your IdP using the provider guides below; nothing on your side requires OpenCX to be in the room.

​
Why SSO

When someone leaves, disabling them in your directory removes their OpenCX access on their next login attempt. No orphaned accounts, no shared passwords to rotate. Your directory stays the single source of truth for who works there.
OpenCX never sees your users’ passwords. Length rules, rotation, hardware-key MFA, conditional access, impossible-travel blocks: every policy you already run in your IdP applies to OpenCX automatically.
Map IdP groups to OpenCX roles once. Move someone into your “Support Leads” group and they become an OpenCX admin on next login. No per-user changes in OpenCX. See Provisioning & role mapping.
Every OpenCX login shows up in your IdP’s sign-in logs alongside the rest of your stack, so security reviews and access certifications cover OpenCX with the tooling you already have.

​
Pick your provider

Every provider below terminates at the same OpenCX connection. Pick the guide that matches your IdP. If yours isn’t listed, use the generic SAML or OIDC guide; anything standards-compliant works.

Microsoft Entra ID

Formerly Azure AD. SAML enterprise application, with optional SCIM provisioning and Conditional Access.

Okta

SAML app integration from the Okta catalog, with group push and SCIM.

Google Workspace

Custom SAML app from the Google Admin console.

Any SAML 2.0 IdP

OneLogin, JumpCloud, Ping Identity, Duo, Auth0, or on-prem AD FS: the standards-compliant path.

Any OIDC provider

OpenID Connect via authorization-code flow for IdPs you’d rather run over OIDC than SAML.

Provisioning & role mapping

JIT provisioning, SCIM, and mapping directory groups to OpenCX roles.

​
Protocols

OpenCX supports both major federation protocols. Pick whichever your IdP handles best; they deliver the same result.
If you’re unsure, choose SAML 2.0. It’s the default for Microsoft Entra ID, Okta, and Google Workspace, and every provider guide in this section leads with it.

​
How a login works

Two ways your team reaches the IdP:
  • SP-initiated: a member goes to platform.open.cx, enters their work email, and OpenCX redirects them to your IdP based on the email domain bound to your organization.
  • IdP-initiated: a member clicks the OpenCX tile in their IdP dashboard (the Okta/Entra/Google app portal) and lands in OpenCX already authenticated.

​
Provisioning

New members don’t need to be created in OpenCX ahead of time.
  • Just-in-time (JIT): the default. The first time someone authenticates through your IdP, OpenCX creates their member record from the identity attributes in the assertion (email, name) and assigns a role from your group mapping.
  • SCIM 2.0: available on request. Your IdP pushes create / update / deactivate events to OpenCX so members are provisioned and, critically, deprovisioned without waiting for a login attempt. Recommended for larger teams and tighter offboarding SLAs. See Provisioning & role mapping.

​
Enforcement & break-glass

Once your connection is verified, OpenCX can enforce SSO per organization: every member must authenticate through your IdP, and email + password login is turned off for your domain.
Enforcement is deliberate and reversible only by OpenCX while SSO is not yet self-serve. Before you ask us to flip it on, confirm every active member resolves through your IdP. See the pre-cutover checklist.
To protect you against IdP outages, one break-glass account, the billing owner by default, keeps email + password access even when enforcement is on. Store its credentials in your password manager or privileged-access vault, and put a hardware-key MFA on it.

​
What you’ll need

Before you start a provider guide, gather:
1

Your IdP and admin access

You need admin rights in the IdP to create an enterprise app and exchange metadata. Each guide lists the exact role required.
2

Your OpenCX organization ID

Find it at Settings → Organization. You’ll give this to your OpenCX contact so we bind the connection to the right tenant.
3

The email domain(s) to bind

The domains your members log in with (e.g. acme.com, acme.io). OpenCX routes SP-initiated logins to your IdP based on these. Verify you own them.
4

Your OpenCX SP details

After we open the connection, you’ll receive your connection-specific ACS URL, SP entity ID, and (for OIDC) redirect URI. Each provider guide shows exactly where these go.