Single sign-on

Let your company's own sign-in decide who works in Help: your team signs in through your provider instead of with a code we email, and someone who leaves your company can no longer sign in. Any provider that speaks OpenID Connect works, such as Microsoft Entra ID, Google Workspace, Okta, Auth0 or Keycloak. It's on the Business plan.

Only the workspace's owner sets it up, under Settings → Single sign-on. It takes four steps.

1. Prove your email domain

Add the domain your team's addresses end in, such as acme.com, and publish the TXT record the page shows where you manage that domain:

It's the same record Settings → Domains asks for, so a domain you already proved there by DNS counts at once. Press Check once the record is published; a new record can take a few minutes to show. A domain belongs to one workspace at a time, and we look at the record again every day. If it goes missing we email you, and after seven days your provider stops signing people in at that domain until the record is back.

Mail services anyone can sign up to, such as gmail.com, can't be claimed.

2. Make an app at your provider

Make a web app (sometimes called a client or an application) for the authorization code flow, and give it the sign-in address the settings page shows:

https://help.deltabreen.eu/api/auth/sso/callback

Then copy three things back into Help:

We ask your provider for its settings when you save, so a mistyped issuer is caught there. The client secret is kept sealed and never shown again; to change it, paste a new one.

Your provider must sign its ID tokens with a public key (RS256, ES256, EdDSA and the like) and offer PKCE with S256. Every major provider does. Its addresses must use https on the standard port.

Where to find the issuer:

Help reads the person's address from the email claim, and refuses one your provider says it never confirmed (email_verified: false). If your provider puts the address elsewhere, name that claim under More settings.

3. Run a test sign-in

Press Run a test sign-in and sign in at your provider as anyone at your domain. A test signs nobody in to Help; the page then says whether it passed, and as whom. It must pass before you can require single sign-on.

4. Choose who can join, and whether to require it

Who can join. With Invited people only, your provider signs people in, and they work in your workspace once you invite them; anyone else your provider lets in signs in to a workspace of their own. With Anyone your provider lets in, someone at your domain who signs in joins your workspace as an agent, within your plan's people. Someone you removed is not brought back by single sign-on; an invite brings them back.

Require it. Everyone at your proved domains then signs in through your provider, is signed out now, and an emailed code no longer works for them. The same goes for a domain you prove later. You keep an emailed code, as the owner, so a broken setup never locks you out. A session from your provider lasts a day, and counts as the second step when your workspace requires two-step sign-in. Changing the provider's issuer or client ID turns the requirement off until a test passes again.

When someone leaves

Turning someone off at your provider stops them signing in through it, and a session it gave ends within a day. While you require single sign-on, an AI assistant they connected keeps working only while they've signed in through your provider in the last 30 days, since your provider can't tell us they left. Remove them on the Team page to stop everything at once.

On a smaller plan

On a smaller plan single sign-on is paused: nothing is required, codes work for everyone, and your settings are kept for when you're back on Business.

Signing in

On the sign-in page, a person types their address. When your provider serves that domain, the page offers your company's sign-in (by the button name you chose, under More settings), and only that when you require it. They come back signed in.