Skip to main content
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. 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

1

Verify your domain

Publish the DNS TXT record from Verified Domains and select Re-check.
2

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).
3

Test sign-in

Sign in through SSO in a private browser window as an Owner or Admin.
4

Add directory sync (optional)

Create a SCIM directory so your IdP manages membership and roles.
5

Require SSO (optional)

Once a test sign-in has succeeded, turn on mandatory SSO.

​
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.
  • 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, or let 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.

​
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.

​
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 for which providers support SLO.

​
Current limitations

  • 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.