Single sign-on

Single sign-on lets people use your organisation's identity provider instead of a password here. Access is granted and revoked where the rest of your access already lives.

Setting it up needs the owner role, and on deployments that sell it, a plan that includes it.

Connecting a provider

Settings → SSO & SCIM. You can register either kind:

• OIDC (Okta, Entra ID, Google Workspace, Auth0 and most modern providers). You need the issuer URL, a client id and a client secret from an application you create there.
• SAML for providers that only speak SAML. You supply the entity id, the sign-in URL and the certificate.

Set your email domain on the connection. That is what lets somebody type their work address on the sign-in page and be sent to the right provider.

The redirect URL to paste into your provider is shown on the page; it is specific to the connection you are creating.

Signing in

Once connected, people type their work email on the sign-in page and choose Continue with SSO. First time through, an account is created here and linked to the identity from your provider.

Requiring it

Under Settings → Security policies you can require SSO for the workspace. Members who are not linked to the provider are stopped with an explanation and a route to sign in properly.

One thing to be precise about: requiring SSO means each member has an account linked to your provider. A member who is linked can still sign in here with their password if they know it. If you need provider-only sign-in, enforce that at the identity provider, which is where that control belongs.

Removing access

Removing somebody in your identity provider stops them signing in through it. It does not by itself remove their membership here; use SCIM provisioning if you want removal there to remove them here automatically, or remove them by hand from Settings → Workspace.