Single sign-on

Let your team sign in with the account they already have at your own identity provider — Okta, Entra ID, Google Workspace, or anything else that speaks OpenID Connect. Company admins set this up themselves from Profile → Single sign-on.

Setting up takes three steps, and the order matters: each one is blocked until the one before it is done.

Step 1 — Prove you own an email domain

Add the domain your team's email addresses use (the part after the @), then publish the TXT record shown on the card and press Check DNS.

The email domains step showing one verified domain and one still awaiting DNS, each with its record name, type and value — One domain verified, one still waiting for its DNS record to propagate.

A verified domain is what gives your provider the right to speak for those addresses. Without it a sign-in through your provider proves only where the assertion came from, not who it may speak for — so every one of them gets turned away.

Two things worth knowing:

Public providers can't be claimed. gmail.com, outlook.com and the like are refused outright — nobody controls their DNS, so nobody could ever verify them.
A domain belongs to one company across the whole platform. If it's already claimed, adding it again is refused.

DNS changes take time to spread. A first check failing is ordinary, not a sign something is wrong — the error names the exact record it looked for, so you can compare it against what your DNS provider actually published. Press Check DNS again after a few minutes.

Step 2 — Connect your identity provider

This step is circular by nature, so start with the redirect URI: you can't register Oiva in your provider without knowing where it sends people back, and you can't get a client ID and secret without registering it first.

The identity provider step showing the redirect URI, issuer URL, client ID, client secret and the role given to new people — Copy the redirect URI into your provider, then bring back the issuer, client ID and secret.

Copy the Redirect URI and add it to your provider's app configuration as an allowed redirect (some providers call it a sign-in callback URL).
Paste back the Issuer URL — the base URL of your tenant, such as https://acme-analytics.okta.com.
Paste the Client ID and Client secret your provider issued.
Pick the Role for new people — what somebody gets the first time they arrive through this provider. Manager unless you have a reason otherwise; admins can change billing.
Turn on Accept sign-ins through this provider and press Save.

Only the issuer is stored. The authorize and token endpoints and the signing keys are read from its discovery document each time, so rotating keys on your side needs nothing from you here.

Saving reaches your provider once to confirm the issuer is real, rather than letting a typo surface at somebody's first login. If it can't read the configuration, the error names the issuer it tried.

The client secret is stored encrypted and never shown again. When you edit the provider later the field is empty and says so — leave it blank to keep the stored secret, or type a new one to replace it.

Step 3 — Require single sign-on

The last step is separate from the one before it on purpose, and the gap between them is where you confirm sign-in actually works for your people. Have somebody sign in through the provider first.

The final step: a switch requiring everyone in the company to sign in through the provider — Turn this on once somebody has successfully signed in through your provider.

Once required, a password stops getting anyone into this company. Membership of any other company is untouched — the requirement belongs to the membership, not to the person.

Turning it back off never asks for confirmation. That's the direction that restores access, so it's always one click away.

If no admin of the company has an email address inside a verified domain, this switch is blocked outright — turning it on would leave nobody able to sign in and undo it. Invite an admin on a verified domain first and have them sign in once. If your own address is the one outside, you'll get a separate warning: another admin can still switch it off for you.

Who gets which role

Somebody arriving through your provider for the first time gets an account automatically, with the default role you set in step 2.

An invitation changes that. Invite someone at an address inside a verified domain and the invitation becomes a role reservation: their first sign-in through the provider consumes it and they land with the role you picked instead of the default. So you can seed an admin before they have ever signed in.

A contractor on a personal address still gets the ordinary password invitation — your provider can't vouch for an address it doesn't own.

If your first admin used a personal address

Single sign-on is something an existing admin turns on, so somebody always signs up the ordinary way first. If that person used a company address, nothing needs doing: their first sign-in through the provider links to the account they already have, and they keep their company, role and everything they own.

If they used a personal address, the two never meet — gmail.com isn't a domain you can verify — and they'll keep landing on the password form. To move across:

If single sign-on is already required, switch it off first. The Employees page is subject to that requirement; this settings page never is, so you can always reach it.
Invite somebody on the verified domain as Admin.
They sign in through the provider and arrive as an admin.
Remove the personal-address membership from Employees. This removes the company membership; their own account is unaffected.
Turn the requirement back on.

Easiest is to avoid it: whoever signs your company up should use a company email address.