# Set up single sign-on

> Source: https://elaichi.ai/docs/guides/settings/single-sign-on/

Let members sign in with your company’s identity provider (OIDC or SAML), route verified email domains to the right connection, and optionally require SSO for those domains. SCIM provisioning and group → role mappings live on the same Settings tab.

**Where to find it:** **Settings → SSO**

You need **Manage SSO** (`sso:manage`). The SSO tab is hidden without it. SSO, SCIM, and group mappings are **Black plan** features — on other plans the tab shows that SSO is not in your plan.

```mermaid title="How SSO and domains fit together"
flowchart TD
  Email["User enters work email"] --> Resolve["Domain routing"]
  Resolve --> Conn["SSO connection<br/>OIDC or SAML"]
  Conn --> IdP["Identity provider"]
  IdP --> Session["Signed-in Elaichi session"]
  SCIM["SCIM provisioning"] --> Members["Org members + groups"]
  Members --> Map["Group → role mappings"]
  Map --> Roles["Elaichi roles"]
```

## What you configure on this tab

| Section | Purpose |
| --- | --- |
| **SSO connections** | Create OIDC or SAML IdP connections; activate, enforce, set default |
| **Domain routing** | Map each verified domain to a connection (or org default) |
| **SCIM provisioning** | Base URL + bearer tokens for directory sync — see [SCIM](/guides/sso/scim-provisioning) |
| **Group role mappings** | Map SCIM groups to Elaichi roles |

## OIDC vs SAML

When you create a connection, pick a protocol (fixed after create):

### OIDC

Configure:

- **Issuer / discovery URL**
- **Client ID**
- **Client secret** (stored encrypted; leave blank on edit to keep the current secret)

### SAML

Either paste **Identity provider metadata XML** (fills the fields) or set manually:

- **Identity provider entity ID**
- **Identity provider SSO URL**
- **Identity provider X.509 certificate**
- **Sign AuthnRequests** — on/off
- **Allow identity provider-initiated login** — on/off

After the connection exists, Elaichi shows **URLs to configure in your identity provider** (copy each). Create the connection first, paste those URLs into the IdP, then fill IdP details and activate.

## Create a connection (safe inactive start)

Connections are meant to be configured **inactive** until ready:

1. Open **Settings → SSO**.
2. Choose **New connection**.
3. Select **OIDC** or **SAML**, give it a **Name**, and create it.
4. Copy the generated URLs into your IdP app.
5. Complete the protocol fields (and default role if you want something other than Member for provisioned joiners).
6. Turn **Active** on only when required fields are complete. Activation fails if the config is incomplete — the editor reopens so you can finish.

Optional switches on the connection:

| Switch | Effect |
| --- | --- |
| **Active** | Connection can be used for sign-in |
| **Default connection** | Used for verified domains set to **Org default** |
| **Enforce SSO** | Members on linked verified domains must use SSO (social + magic link refused). Only available while active. |

**Default role for provisioned members** — role assigned when SSO / JIT creates membership if no other mapping applies. Empty means **Member**.

From the connections table you can also toggle Active / Enforced, **Make default**, edit, or delete. Deleting disconnects anyone relying on that IdP — update domain routing first.

## Domain routing

1. [Verify domains](/guides/settings/verify-a-domain) under **Settings → Domains**.
2. On **SSO → Domain routing**, for each verified domain pick a connection or **Org default**.

Unverified domains do not appear here. Email → IdP resolution on the login screen depends on this mapping.

## Recommended rollout

1. Create the connection **inactive**; finish IdP config.
2. Link a verified domain (or use default).
3. Activate and test with a known account.
4. Only then turn on **Enforce SSO**.

## Good to know

- Multiple connections are supported (for example separate IdPs per domain).
- Enforcement requires the connection to be active; enforced without a working IdP locks people out of social/magic paths for that domain.
- SCIM is independent of SSO login but usually deployed together — see [SCIM provisioning](/guides/sso/scim-provisioning).

## Related

- [Verify a domain](/guides/settings/verify-a-domain)
- [Provisioning members with SCIM](/guides/sso/scim-provisioning)
- [Roles and permissions](/guides/members/roles)
- [Manage billing](/guides/settings/billing)
- [Sign in](/guides/basics/sign-in)