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

# Single sign-on overview

> How Odin single sign-on works over SAML 2.0 and OpenID Connect, and what you need before you start

Single sign-on (SSO) lets your team sign in to Odin through your own identity provider (IdP), such as Okta, instead of one-time codes, passkeys, Google or GitHub. Odin supports **SAML 2.0** and **OpenID Connect (OIDC)**, and can keep your team in sync with your directory over **SCIM 2.0**.

Everything is configured by an Owner or Admin from **Organisation Settings → Single Sign-On**.

## What you need

* **A plan that includes single sign-on.** If yours does not, the card offers **Contact the team about single sign-on**.
* **A domain verified with a DNS TXT record.** SSO only applies to email addresses on domains you have proved you own. See [Verified domains](/platform/organisation-settings#verified-domains). A Mjolnir file or CNAME check is not enough.
* **Admin access to your identity provider**, to create an application for Odin.

## How it fits together

| Capability | What it does | Page |
| - | - | - |
| **SSO connection** | Your IdP authenticates people; Odin trusts it for your verified domains | [Set up single sign-on](/platform/sso/set-up) |
| **Mandatory SSO** | Blocks every other sign-in method for your verified domains | [Mandatory SSO](/platform/sso/mandatory-sso) |
| **Directory sync (SCIM)** | Creates, updates and removes members, and maps IdP groups to Odin roles | [Directory sync](/platform/sso/directory-sync) |
| **Provider guides** | Exact settings for Okta, Microsoft Entra ID, Auth0, JumpCloud and Keycloak | [Identity providers](/platform/sso/identity-providers) |

<Steps>
  <Step title="Verify your domain">
    Publish the DNS TXT record from **Verified Domains** and select **Re-check**.
  </Step>

  <Step title="Connect your identity provider">
    Create an application in your IdP with the values Odin shows, then give Odin the IdP's metadata (SAML) or discovery URL and credentials (OIDC).
  </Step>

  <Step title="Test sign-in">
    Sign in through SSO in a private browser window as an Owner or Admin.
  </Step>

  <Step title="Add directory sync (optional)">
    Create a SCIM directory so your IdP manages membership and roles.
  </Step>

  <Step title="Require SSO (optional)">
    Once a test sign-in has succeeded, turn on mandatory SSO.
  </Step>
</Steps>

## How people sign in

* **From Odin**: people enter their work email and select **Continue with email**. Odin recognises the verified domain and sends them to your IdP. There is no separate SSO button. See [Logging in](/getting-started/logging-in#sign-in-with-single-sign-on).
* **From your identity provider** (SAML only): people can launch Odin from their IdP dashboard or app launcher, such as an Okta tile. Odin applies the same checks as when sign-in starts from Odin.

On first sign-in, Odin creates the person's account and adds them to your organisation as a **Member**, which uses a seat. Their name comes from the IdP's first-name and last-name claims when present.

Seats work as they do for invitations. If your plan bills extra seats, a new SSO member adds one to your bill. If your organisation has a fixed seat limit and no seat is free, the person cannot join until an Admin adds seats or removes someone. Enterprise contracts are not blocked; usage is reported for your account manager. Change roles in [Team Management](/platform/team-management), or let [directory sync](/platform/sso/directory-sync) manage them.

With directory sync, you can stop SSO from adding people at all, so only people your directory provisions can join. See [Access](/platform/sso/directory-sync#access).

## What Odin checks on every SSO sign-in

Odin does not trust an assertion just because it is validly signed. Each sign-in must also pass these checks:

* The assertion must come from **your organisation's** connection. Another organisation's IdP cannot sign anyone into your workspace.
* The email must be on one of the connection's **verified domains**.
* The email must not be marked **unverified** by your IdP. Odin refuses explicitly unverified addresses, so someone who can self-register at your IdP cannot claim an existing person's email.
* The person must not have been **removed by directory sync**.

If a check fails, the person returns to the sign-in page with an explanation. See [Troubleshooting](/platform/sso/troubleshooting).

## Signing out

* **SAML**: Odin always ends the Odin session first. If your IdP supports single logout (SLO), Odin then signs the person out of the IdP too.
* **OIDC**: Odin ends the Odin session. The IdP session stays, so the next sign-in may not ask for a password.

See [Signing out and single logout](/platform/sso/set-up#signing-out-and-single-logout) for which providers support SLO.

## Current limitations

<Warning>
  * **Signed authentication requests are not supported yet.** If your IdP can require signed SAML requests (for example Keycloak's **Client signature required**), turn that setting off.
  * **Single logout** works with Okta over the HTTP-POST binding, and Microsoft Entra ID signs people out when its Logout Url is left empty. Auth0, Keycloak and JumpCloud do not complete Odin's logout request; Odin still ends the Odin session.
  * **One connection per organisation.** Saving a new identity provider replaces the previous one.
</Warning>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.