> ## Documentation Index
> Fetch the complete documentation index at: https://docs.open.cx/llms.txt
> Use this file to discover all available pages before exploring further.

# Single sign-on (SSO)

> Log your team into OpenCX through your own identity provider, Microsoft Entra ID, Okta, Google Workspace, or any SAML 2.0 / OIDC IdP. Covers protocols, provisioning, role mapping, and prerequisites.

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.

<Note>
  SSO is available on **Enterprise** plans and is enabled by OpenCX during onboarding; it isn't self-serve from the dashboard yet. Contact [sales@open.cx](mailto:sales@open.cx) 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.
</Note>

## Why SSO

<AccordionGroup>
  <Accordion title="One identity, one offboarding switch" icon="user-lock">
    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.
  </Accordion>

  <Accordion title="Your password and MFA policy, enforced" icon="shield-halved">
    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.
  </Accordion>

  <Accordion title="Roles that follow your directory groups" icon="users-gear">
    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](/security/sso/scim).
  </Accordion>

  <Accordion title="A single audit trail" icon="clipboard-list">
    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.
  </Accordion>
</AccordionGroup>

## 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.

<CardGroup cols={2}>
  <Card title="Microsoft Entra ID" icon="microsoft" href="/security/sso/microsoft-entra">
    Formerly Azure AD. SAML enterprise application, with optional SCIM provisioning and Conditional Access.
  </Card>

  <Card title="Okta" icon="o" href="/security/sso/okta">
    SAML app integration from the Okta catalog, with group push and SCIM.
  </Card>

  <Card title="Google Workspace" icon="google" href="/security/sso/google-workspace">
    Custom SAML app from the Google Admin console.
  </Card>

  <Card title="Any SAML 2.0 IdP" icon="right-to-bracket" href="/security/sso/generic-saml">
    OneLogin, JumpCloud, Ping Identity, Duo, Auth0, or on-prem AD FS: the standards-compliant path.
  </Card>

  <Card title="Any OIDC provider" icon="fingerprint" href="/security/sso/oidc">
    OpenID Connect via authorization-code flow for IdPs you'd rather run over OIDC than SAML.
  </Card>

  <Card title="Provisioning & role mapping" icon="users-gear" href="/security/sso/scim">
    JIT provisioning, SCIM, and mapping directory groups to OpenCX roles.
  </Card>
</CardGroup>

## Protocols

OpenCX supports both major federation protocols. Pick whichever your IdP handles best; they deliver the same result.

|                  | SAML 2.0                                                                  | OpenID Connect (OIDC)                                  |
| ---------------- | ------------------------------------------------------------------------- | ------------------------------------------------------ |
| **Best when**    | Your IdP's default enterprise app is SAML (Entra ID, Okta, Google, AD FS) | You prefer OAuth 2.0 tooling or your IdP is OIDC-first |
| **You exchange** | IdP metadata XML ↔ SP entity ID + ACS URL                                 | Issuer URL, client ID, client secret ↔ redirect URI    |
| **Signing**      | SAML response and assertion signed by your IdP                            | ID token signed via your IdP's JWKS                    |
| **Provisioning** | JIT + optional SCIM                                                       | JIT + optional SCIM                                    |

<Tip>
  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.
</Tip>

## How a login works

```mermaid theme={"dark"}
flowchart LR
  A[User opens platform.open.cx] --> B[OpenCX detects your email domain]
  B --> C[Redirect to your IdP]
  C --> D[IdP authenticates + applies MFA / conditional access]
  D --> E[Signed assertion returned to OpenCX]
  E --> F[OpenCX maps groups to a role]
  F --> G[Session issued: user lands in the Inbox]
```

Two ways your team reaches the IdP:

* **SP-initiated**: a member goes to [platform.open.cx](https://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](/security/sso/scim).
* **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](/security/sso/scim).

## 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.

<Warning>
  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](/security/sso/troubleshooting#before-you-enforce).
</Warning>

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:

<Steps>
  <Step title="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.
  </Step>

  <Step title="Your OpenCX organization ID">
    Find it at [**Settings → Organization**](https://platform.open.cx/settings). You'll give this to your OpenCX contact so we bind the connection to the right tenant.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## Related

* [Provisioning & role mapping](/security/sso/scim): JIT, SCIM, and group → role rules.
* [Troubleshooting SSO](/security/sso/troubleshooting): common assertion, attribute, and enforcement errors.
* [Bug bounty program](/security/bug-bounty): report a vulnerability in our SSO implementation or anywhere else.