Single Sign-On (SSO)

Single Sign-On lets your team sign in to Sim through your company's identity provider instead of managing separate passwords. Sim supports both OIDC and SAML 2.0, and an organization can use more than one identity provider at a time, one per verified domain.

Before you start

Decide your Provider ID before configuring your identity provider. It becomes part of the callback URL you register there, and it is fixed once saved — changing it later means deleting the provider and setting it up again.

Setup

1. Open SSO settings

Go to Settings → Organization → Single sign-on. The page has three tabs:

Use Domains to verify ownership, then return to Sign-in to configure your provider. Switching tabs preserves an unsaved sign-in draft while you stay on this page; use Save or Update to commit it. The selected tab and provider are included in the URL, so they can be bookmarked or shared. On self-hosted deployments, Provisioning appears when SCIM is enabled.

An organization can run several identity providers at once, each serving a different verified domain: Okta for eng.acme.com and Microsoft Entra ID for acme.com, for example. Sign-in lists them; select Add identity provider for another, or a row to view, edit, or delete one. Sim routes each sign-in by the email domain, so a domain routes to exactly one provider.

2. Choose a protocol

3. Fill in the form

Fields required for both protocols:

OIDC additional fields:

SAML additional fields:

4. Copy the callback URL

Copy Callback URL for OIDC or ACS URL (Reply URL) for SAML. This is the endpoint that receives your identity provider's authentication response. Register it in your IdP before saving. If you set a SAML Callback URL override under Advanced options, the copyable ACS URL uses that override.

OIDC providers (Okta, Microsoft Entra ID, Google Workspace, Auth0):

https://<your-sim-domain>/api/auth/sso/callback/{provider-id}

SAML providers (ADFS, Shibboleth):

https://<your-sim-domain>/api/auth/sso/saml2/callback/{provider-id}

5. Save and test

Click Save. To test, sign out and use the Sign in with SSO button on the login page. Enter an email address at your configured domain — Sim will redirect you to your identity provider.

Editing and advanced configuration

For a saved connection, open Sign-in, select the provider, and select Edit. The Provider ID remains fixed. Delete removes that sign-in path only: accounts and memberships it admitted stay, and people at its domain sign in another way until a provider serves the domain again. A saved OIDC client secret appears as a mask with a suffix when available; Replace lets you enter a new secret, and Keep saved cancels that replacement. Select Update to save the provider, or Discard to abandon changes.

Advanced options contains OIDC scopes and optional authorization, token, and JWKS endpoint overrides. For SAML, it contains Audience, Callback URL override, signed-assertion requirements, NameID format, and optional IdP metadata XML. Attribute mapping lets either protocol override the email, name, and stable user-ID claim names. Leave a mapping blank to use the protocol default.

SCIM settings save immediately in the Provisioning tab. Its Disable just-in-time provisioning rule overrides Automatic first-sign-in membership while the connection is active and entitled. Existing members can still sign in. See directory provisioning.

Follow the Okta or Microsoft Entra provisioning walkthrough to connect a SCIM app and verify synchronization separately from sign-in.

Provider Guides

How sign-in works after setup

Once SSO is configured, users with your domain (company.com) can sign in through your identity provider:

1. User goes to sim.ai and clicks Sign in with SSO
2. They enter their work email (e.g. alice@company.com)
3. Sim looks up the provider that serves company.com and redirects them to it
4. After authenticating, they are returned to Sim
5. If First sign-in is Automatic, Sim adds them to the organization as a Member, growing a Team seat count or validating available fixed-seat capacity
6. They land in an accessible workspace, or see a clear no-access state until an admin grants workspace access

With Automatic provisioning, no invitation is required for organization membership. The join follows the organization's seat policy and does not infer a role from IdP claims: every newly provisioned user starts as a Member. Team subscriptions grow their billed seat count with membership; fixed-seat plans reject the join when capacity is full. With Invite only, SSO proves identity but does not create new membership or workspace access; new access must be granted separately, while existing organization membership and workspace access remain available.

SSO provisioning creates internal organization members but does not grant workspace access. To grant workspace access from your identity provider, use directory provisioning and map a pushed group to a workspace. External workspace members are different: they are invited to a specific workspace without joining your organization or consuming one of your seats. Existing invitations and external access take precedence over automatic provisioning so their intended role and workspace grants are preserved.

Self-hosted setup

Self-hosted deployments use environment variables instead of the billing/plan check.

Environment variables

# Required
SSO_ENABLED=true
NEXT_PUBLIC_SSO_ENABLED=true

# Optional: directory provisioning (SCIM), configured from Single sign-on → Provisioning
SCIM_ENABLED=true
NEXT_PUBLIC_SCIM_ENABLED=true

# Required if you want users auto-added to your organization on first SSO sign-in
ORGANIZATIONS_ENABLED=true
NEXT_PUBLIC_ORGANIZATIONS_ENABLED=true

# Optional: comma-separated provider IDs to trust for automatic account linking.
# This applies to non-SSO providers only — SSO linking is authorized by the
# verified domain on the provider itself, not by this list.
SSO_TRUSTED_PROVIDER_IDS=custom-oidc,partner-saml

You can register providers through the Settings UI (same as cloud) or by running the registration script directly against your database.

Script-based registration

Use this when you need to register an SSO provider without going through the UI — for example, during initial deployment or CI/CD automation.

# OIDC example (Okta)
SSO_ENABLED=true \
NEXT_PUBLIC_APP_URL=https://your-instance.com \
SSO_PROVIDER_TYPE=oidc \
SSO_PROVIDER_ID=okta \
SSO_ISSUER=https://dev-1234567.okta.com \
SSO_DOMAIN=company.com \
SSO_USER_EMAIL=admin@company.com \
SSO_OIDC_CLIENT_ID=your-client-id \
SSO_OIDC_CLIENT_SECRET=your-client-secret \
bun run packages/db/scripts/register-sso-provider.ts

# SAML example (ADFS)
SSO_ENABLED=true \
NEXT_PUBLIC_APP_URL=https://your-instance.com \
SSO_PROVIDER_TYPE=saml \
SSO_PROVIDER_ID=adfs \
SSO_ISSUER=https://adfs.company.com/adfs/services/trust \
SSO_SAML_AUDIENCE=https://your-instance.com \
SSO_DOMAIN=company.com \
SSO_USER_EMAIL=admin@company.com \
SSO_SAML_ENTRY_POINT=https://adfs.company.com/adfs/ls \
SSO_SAML_CERT="-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----" \
bun run packages/db/scripts/register-sso-provider.ts

The script outputs the callback URL to configure in your IdP once it completes.

To remove a provider:

SSO_USER_EMAIL=admin@company.com \
bun run packages/db/scripts/deregister-sso-provider.ts