Single sign-on (SSO)

Configure SAML or OIDC so your users log in with company credentials.

Why configure SSO?

Without SSO, users create a password directly on the platform. With SSO, they authenticate through your identity provider — Google Workspace, Microsoft Entra, Okta, or any SAML 2.0 / OIDC-compatible IdP. Once configured, users who hit the login page are redirected to your IdP automatically. No separate credentials to manage, no password resets, and access is revoked the moment you offboard someone in your IdP.

Supported protocols

Both are configured under Organization → SSO.

Setting up SAML

1. In your IdP, create a new SAML application.
2. Set the ACS URL (Assertion Consumer Service) to the value shown in Organization → SSO → SAML → ACS URL.
3. Set the Entity ID (also called Audience URI) to the value shown in the same panel.
4. Map the following attributes from your IdP user profile:
   • email → user's email address (required)
   • firstName → first name (optional)
   • lastName → last name (optional)
5. Download the IdP metadata XML or copy the IdP SSO URL and certificate.
6. Paste those into Organization → SSO → SAML → IdP configuration and save.
7. Click Test configuration — you'll be redirected to your IdP to confirm the flow works end-to-end before it goes live.

Setting up OIDC

1. In your IdP, create a new OIDC application (also called an OAuth2 app or "web application").
2. Set the Redirect URI to the value shown in Organization → SSO → OIDC → Redirect URI.
3. Copy the Client ID and Client Secret from your IdP.
4. Enter the Issuer URL — this is the base URL of your IdP's OIDC discovery endpoint (e.g. https://accounts.google.com for Google, https://login.microsoftonline.com/{tenant-id}/v2.0 for Entra).
5. Paste those values into Organization → SSO → OIDC and save.
6. Click Test configuration to validate.

Going live

Once you've tested and the configuration is saved, toggle SSO → Enabled. From that point:

• All users who visit the login page are redirected to your IdP.
• Users who were previously using a password can no longer log in that way.
• New users provisioned via SCIM (or invited manually) will be required to go through SSO on first access.

To roll back, toggle Enabled off. Existing password-based accounts resume working immediately.

Just-in-time provisioning

When a user authenticates via SSO for the first time and no matching account exists, the platform creates one automatically using the email and name from the IdP assertion. This is called just-in-time (JIT) provisioning.

JIT provisioning respects your org's default role. If you want finer control — pre-assigning users to teams or granting specific skills — use SCIM instead. See the SCIM provisioning guide.

Forcing SSO for all users

If you want to prevent any non-SSO login (including for org admins), enable Enforce SSO in Organization → SSO. Make sure at least one org admin has tested the SSO flow before enabling this — if your IdP configuration breaks, you'll need to contact platform support to regain access.