> For the complete documentation index, see [llms.txt](https://docs.mithrl.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mithrl.com/getting-started/sso-directory-sync.md). # 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 .