# SSO and SCIM provisioning

Let your team log in with your company's identity provider, and keep workspace membership in sync with your directory.

> **Who can use this feature?**
>
> - **Workspace Owners** and **Admins** can set up SSO and SCIM
> - Available on the [Enterprise plan](https://uselora.com/pricing)

## Overview

With single sign-on (SSO), people log in to Lora with the work account your identity provider already manages. With SCIM, your directory adds, deactivates, and removes workspace members for you. You can use either one on its own, but SCIM needs a verified SSO domain first.

## Set up SSO

### Connect an identity provider

1. From your workspace, click **Settings** in the sidebar, then **Identity**.
2. Next to **SSO authentication & SCIM provisioning**, click **Set up** (or **Manage**, if you've already connected a provider).
3. Click **Connect provider** and choose your provider: Microsoft Entra ID, Google Workspace, Okta, another OpenID Connect provider, or SAML 2.0.
4. Click **Continue**. Follow the steps in the dialog to create an app in your identity provider. The dialog shows the redirect URI (or, for SAML, the entity ID and reply URL) to paste there.
5. Enter your first email domain and the connection details from your identity provider, then click **Connect provider**.

### Verify your email domains

People can only log in through SSO with an email address on a domain you've verified. A connection can have up to 10 domains, and each one is verified on its own.

1. From **SSO authentication & SCIM provisioning**, open your identity provider.
2. Under **SSO-approved email domains**, click **Add**, or open the menu on a pending domain and click **Verify**.
3. At your DNS provider, add the TXT record the dialog shows. Copy **Host / name** and **Value** exactly.
4. Click **Verify**.

A domain shows **Pending verification** until DNS has the record, then **Claimed**. DNS changes usually show up within minutes but can take up to 48 hours. The record's value is valid for 7 days. Open the dialog again for a new one.

A domain can be claimed by one workspace at a time, and a subdomain of a domain another workspace has claimed isn't available.

> **Note:** Removing a domain stops SSO for the addresses on it. Those people keep their accounts and log in with an email code instead. A connection always keeps at least one domain.

### Test the connection

Click **Test** next to **Test SSO connection**. Lora logs you in again through your identity provider and shows when the last test succeeded. The test replaces your session with the account the identity provider signed in, so use your own work account.

### Turn the identity provider on or off

Use **Enable identity provider** to pause SSO without removing the connection. While it's off:

- People on your SSO domains log in with an email code instead.
- Owners and Admins can still log in through it, to test it.
- Nobody new joins the workspace through SSO.

Memberships don't change, and SCIM keeps working.

## How people log in

When someone enters an email address on a verified domain on the login page, Lora sends them to your identity provider. If their account is new to the workspace, they join as a **Member**. People on other domains log in the way they always have.

SSO is offered, not required. People on your SSO domains can still log in with an email code, Google, or a passkey unless you change that in [Other domains](#other-domains).

While SSO is on, people can't join the workspace by approved email domain. Settings → Identity shows a notice with a link to your SSO configuration instead of the approved domains list. Your approved domains come back if you turn SSO off.

## Provision members with SCIM

1. Open your identity provider's page, under **SSO authentication & SCIM provisioning**.
2. Turn on **Enable SCIM user provisioning**. It stays disabled until a domain is verified.
3. Under **Token expires after**, choose 90, 180, or 365 days, then click **Connect SCIM**.
4. Copy the **Tenant URL (SCIM base URL)** and the **Secret token** into your directory's provisioning settings. Lora shows the token once.

From then on, your directory manages membership:

| When your directory… | Lora… |
| --- | --- |
| Creates a user or sets them active | Adds them as a Member, or restores a suspended member |
| Deactivates a user | Suspends their membership and frees their seat |
| Deletes a user | Removes their membership. Their shortcuts go to the workspace's oldest Owner |

Lora never deletes the account itself, and your directory can't deactivate or delete a Workspace Owner. Transfer ownership first.

Email addresses outside your verified domains are refused, and a person an Admin removed stays removed unless the directory provisioned them.

### Rotate or revoke tokens

Click **View configuration** next to the switch. **Create new token** adds a second token while the first keeps working, so you can switch your directory without a gap. A connection holds two tokens at most. **Revoke** one to create another.

Turn off **Enable SCIM user provisioning** to disconnect. Every token stops working and current members keep their access.

### Let your directory own names

Turn off **Allow users to change their name** to make the name from your directory read-only in Lora for the people it manages. Everyone else can still change their name. Their email address is always managed by the directory.

> **Tip:** Agree on one source of truth for names before you turn this off. Once it's off, a name only changes in your directory.

## Other domains

**Other domains** sets how people whose email isn't on one of your SSO domains can log in. People on your SSO domains can always use any method.

- **Google authentication** allows logging in with a Google account.
- **Email & passkey authentication** allows logging in with an email or phone code, or a passkey.

If a method is off, people who log in that way see a screen that names the workspace and the methods it accepts, with a button to log out and log in again. Someone who logs in through another company's SSO, say a contractor on their own identity provider, can always open the workspace.

Some rules keep you from locking yourself out:

- You can't turn off the method you're logged in with, unless your email is on an SSO domain. Log in another way first.
- Both methods can only be off while SSO is on and a domain is verified. And while both are off, SSO can't be turned off or removed, and no verified domain can be removed: the people on it would have no way in.
- If only one method is off, you can't remove the SSO domain your own email is on while you're logged in with that method. Log in another way first.
- A session from before this setting existed has to log in again before it can change anything here.
- Turning a method off needs the Enterprise plan. Turning it back on never does.

## Restrict new workspace creation

Under Settings → **Identity**, turn on **Restrict new workspace creation** to stop people on your verified SSO domains from creating other workspaces. Owners and Admins of your workspace are exempt. It's available once a domain is verified.

## FAQ

**Verification says it can't find the TXT record**
DNS can take a while to update. Check that the host is the full name shown in the dialog, and that the value is exactly the one shown. If the dialog says the value expired, publish the new one.

**Someone on our domain can't log in with SSO**
Their domain needs to show **Claimed**, and **Enable identity provider** needs to be on. A new person also needs a free seat to join.

**Someone can't open the workspace after we turned off a login method**
They signed in with a method the workspace no longer accepts. The screen they see lists the accepted ones. They log out and log in again with one of them, or an Admin turns the method back on.

**I can't turn off a login method**
You're logged in with it, the workspace isn't on the Enterprise plan, or turning it off would leave SSO as the only way in without an active SSO connection. The switch's tooltip says which.

**What happens if we downgrade from Enterprise?**
SSO members keep logging in through the existing connection, and login-method and workspace-creation restrictions stay in force. You can turn the connection off or remove it, switch methods back on, and lift the restriction, but not add new restrictions.