For the complete documentation index, see llms.txt. This page is also available as Markdown.

Setting up SSO & Directory Sync

This page is for your organization's IT contact — whoever administers your identity provider (Okta, Microsoft Entra, Google Workspace, etc.). Mithrl will send you a one-time setup link (the Admin Portal); you don't need a Mithrl or WorkOS account to use it, and the link expires once you finish setup or after 30 days, whichever comes first.

The link can cover one or both of:

  • Single Sign-On (SSO) — your users log in to Mithrl through your own identity provider instead of a separate password.

  • Directory Sync — your identity provider becomes the source of truth for who has access. Add, remove, or regroup someone in your own directory, and it's mirrored into their Mithrl access automatically — no separate invite from Mithrl needed per person.

You can do either independently, but Directory Sync is what actually gets you self-service user management day to day. SSO on its own only changes how someone logs in, not who has access.

Setting up SSO

  1. Open the setup link and choose SSO.

  2. Pick your identity provider from the list (Okta, Entra, OneLogin, Google Workspace, and most other SAML/OIDC providers are supported).

  3. Configure the connection. There are two ways to do this — use whichever your IdP supports:

    • Dynamic (recommended): paste your IdP's metadata URL into the Identity provider metadata URL field.

    • Manual: copy three values from your IdP into the portal — the Single Sign-On URL, the Entity ID (issuer), and the X.509 signing certificate.

  4. Click Test sign-in and confirm it succeeds before rolling this out to your team — this is the step that catches a copy-paste mistake before real users hit it.

  5. Once the connection shows as active, your users can sign in through your IdP.

A couple of things worth knowing:

  • If you set up SSO via a metadata URL, WorkOS auto-renews your signing certificate before it expires. If you configured it manually (a pasted certificate, not a URL), you'll need to update it yourself when your IdP rotates it — WorkOS will email you a warning starting 90 days out.

  • Turning on SSO for your organization can disable other sign-in methods (like password) for your users, depending on how your organization is configured — check with Mithrl if you're not sure this is what you want for everyone on day one.

Setting up Directory Sync

  1. Open the setup link (the same one as above, or a separate one Mithrl sends) and choose Directory Sync.

  2. Pick your directory provider — Okta, Microsoft Entra, Google Workspace, and any other SCIM-compliant directory are supported, along with common HRIS systems like Workday and BambooHR.

  3. The portal gives you two values to enter into your IdP's SCIM app configuration: a SCIM Base URL and a Bearer Token. Every provisioning request your IdP sends (user created, updated, deactivated; group membership changed) goes to that URL, authenticated with that token.

    Treat the Bearer Token like a password — it's the one credential in this flow that can drive provisioning against your organization, so don't paste it into a ticket, chat, or email. If it's ever exposed, rotate it from the same Admin Portal screen (or your Directory Sync dashboard); the new token takes effect immediately and the old one stops working.

  4. Map your directory groups to Mithrl roles (Read Only / Member / Admin / Owner) in the portal. This mapping is what actually determines what a synced user can do — without it, someone can be provisioned with no usable access.

  5. Confirm the sync is working: add or update a test user/group in your directory and check that it shows up in the portal's synced user list.

From here, ongoing user management for your organization happens entirely in your own directory — add someone to a mapped group and they get access automatically; remove them and they can no longer sign in, with no separate Mithrl-side step for either. Note that this covers new sign-ins immediately; whether a session that was already active at the moment of removal is cut short right away, versus expiring on its own later, is still being finalized on Mithrl's side — ask your Mithrl contact for the current status if that distinction matters for your security requirements.

Getting help

If anything here doesn't match what you see, or your identity provider isn't listed, contact support@mithrl.com.

Last updated

Was this helpful?