> ## Documentation Index
> Fetch the complete documentation index at: https://docs.utmkit.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Single sign-on

> Let your organization sign in through Okta, Google, Microsoft or another OpenID Connect provider, prove your email domains, and decide whether it is required.

Your organization already decides who works there in one place: its identity provider. Single sign-on makes that provider the door into UTMKit. People on your verified email domains sign in with the account they already have, nobody chases an invitation mail, and when someone is disabled at the provider their next sign-in fails there.

Single sign-on is included in some plans — check the [plans page](https://app.utmkit.co/billing/plans). On a plan without it, the [Single sign-on](https://app.utmkit.co/sso) page says so and offers nothing else. On a plan with it, only an organization owner — an owner of any of its workspaces — sees the controls.

## Providers

Okta, Google, Microsoft, or any other OpenID Connect provider — one connection per organization. Okta and a generic provider also ask for an issuer URL, the address of your provider organization; Google and Microsoft do not.

## Connecting the provider

<Steps>
  <Step title="Save the connection">
    Choose the provider and paste the client ID and client secret from its console. The secret is stored so it cannot be read back and is never shown again; saving the form with the secret blank keeps the one on file. The connection starts as **not tested yet**.
  </Step>

  <Step title="Register the redirect URI">
    The page now shows the redirect URI to register at your provider, with a copy button. Mistyping it is the most common reason the next step fails.
  </Step>

  <Step title="Test the connection">
    Press **Test connection**. You are sent to the provider, sign in with your own account, and come straight back; nobody is signed in by a test. Only a successful test makes the connection **active**, and any credential change sends it back to not tested.
  </Step>
</Steps>

<Note>
  When a test fails, the page shows why. If the provider refused, its own message is shown untranslated, exactly as the provider phrased it, because that is the text you will find in the provider's console.
</Note>

## Claiming your email domains

Single sign-on is offered to an address only once its domain is proven to be yours. Under **Email domains**, type the domain and press **Claim**. The page shows a TXT record — a name and a value — to publish at your DNS provider. The domain reads **waiting for DNS** until the record is seen and **verified** afterwards. **Re-check DNS** asks for a check now; the record is also re-checked daily, so a domain whose record disappears drops back to waiting and the owners are emailed.

A domain can be claimed by one organization only, and public mail providers cannot be claimed. **Show record** reveals the TXT record again; **Remove** stops offering single sign-on for that domain.

## What people see

On the sign-in page, typing an address on a verified domain shows **Continue with** your provider. The provider signs the person in and they land in the workspaces they have been invited to; a first-timer gets an account created on the spot, with no password. Any other address sees the ordinary sign-in — the page never reveals which domains are claimed. The provider must vouch for the address as verified, and it must be on one of your verified domains; anything else is refused.

## The policy

Once a connection exists, three settings appear under **Policy**:

* **Require single sign-on.** Magic links and passwords are refused for addresses on your verified domains, the sign-in page points them to the SSO button, and no mail is sent. Until then, SSO is an option alongside the ordinary sign-in.
* **Owner break-glass.** On by default. While SSO is required, organization owners can still request a magic link, so a broken provider cannot lock everyone out. Every use is recorded and emailed to all owners. You can turn it off knowingly.
* **Maximum SSO session.** How long a session opened through SSO lasts before the person must sign in again, so off-boarding at the provider takes effect within that window.

A sign-in through SSO satisfies a workspace's [two-factor requirement](/en/security/two-factor): the provider is where your organization enforces multi-factor authentication.

## Turning it off

**Turn off** on an active connection returns everyone to the ordinary sign-in on their next attempt. Roles, workspaces and tokens are untouched throughout: single sign-on decides who you are, never what you may see.