> ## Knowledge Base Index > Fetch the complete knowledge base index at: https://help.lido.app/sitemap.xml > Use this file to discover available pages before exploring further. > Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash). # SSO setup with SAML Single Sign-On (SSO) lets your team sign in to Lido using your existing identity provider (IdP) — Okta, Azure AD, Google Workspace, OneLogin, JumpCloud, etc. SSO is available on **Enterprise** plans. This article covers the SAML 2.0 setup flow at a high level. The exact steps in your IdP's admin UI vary by provider; pair this with your IdP's "create a new SAML app" documentation. --- ## Why SSO - **Centralized access control.** When an employee leaves, removing them from your IdP removes their Lido access automatically. - **Stronger security.** Enforce MFA, conditional access policies, etc. through your IdP rather than per-app. - **Simpler onboarding.** New hire is provisioned in your IdP → they can sign in to Lido immediately. - **Audit-friendly.** Your IdP's logs show who signed in to Lido and when. --- ## Before you start Confirm: 1. You're on an **Enterprise** plan (or have an active SSO add-on). 2. Your IdP supports SAML 2.0. (All major IdPs do — Okta, Azure AD, Google Workspace, OneLogin, Ping, JumpCloud, etc.) 3. You're a workspace **Owner** in Lido and an **admin** in your IdP. 4. You've decided whether to enforce SSO-only sign-in or allow password fallback (see "Enforce SSO" below). --- ## High-level flow SAML is a two-way trust: 1. Lido (the **Service Provider**) needs to trust your IdP — you give Lido your IdP's metadata (a URL or XML file). 2. Your IdP needs to trust Lido — you create a new "SAML app" in your IdP and give it Lido's metadata. After both sides trust each other, users at your IdP click "Lido" (or sign in via a SP-initiated link) and land in their Lido workspace, signed in. --- ## Step-by-step ### 1. Get Lido's SAML configuration In Lido: workspace settings → **Single Sign-On** (visible on Enterprise). Lido displays: - **Entity ID (Audience URI):** unique identifier for your Lido workspace. - **Reply URL (ACS URL):** where your IdP sends the SAML response. - **Sign-in URL** (for IdP-initiated flow). Copy these — your IdP will ask for them. ### 2. Create a SAML app in your IdP Open your IdP admin console. Create a new SAML 2.0 application. Walk through whatever wizard your IdP provides; when prompted: - **Entity ID / Audience:** paste from Lido. - **Single Sign-On URL / Reply URL / ACS URL:** paste from Lido. - **Name ID format:** Email Address (recommended) or Persistent. - **Attribute mapping:** at minimum, send the user's email. Common attributes Lido reads: - `email` — required - `firstName` — optional - `lastName` — optional - `groups` — optional, used for role mapping if you want IdP groups to control Lido roles Save the app. ### 3. Get your IdP's SAML metadata Your IdP should now expose: - A **metadata URL** (preferred; Lido fetches it dynamically), or - A downloadable **metadata XML file**. Plus: - **IdP SSO URL** (the URL Lido redirects users to for sign-in). - **X.509 signing certificate**. Copy or download these. ### 4. Configure Lido with your IdP's metadata Back in Lido → SSO settings: - Paste the IdP metadata URL, **or** upload the metadata XML. - Lido auto-fills the SSO URL and certificate from the metadata. - (Optional) Configure attribute mapping if your IdP uses non-default attribute names. - (Optional) Map IdP groups to Lido roles. Save. ### 5. Test before enforcing Critical: **test SSO with a non-admin user before enforcing it on the workspace.** 1. In your IdP, assign yourself the SAML app. 2. Open an incognito window. 3. Go to the IdP's app launcher and click Lido (or use Lido's sign-in URL with your workspace). 4. You should land in Lido, signed in. If anything fails (wrong entity ID, missing attribute, certificate mismatch), the SAML response includes a clear error message. Fix and re-test. ### 6. Roll out Once test succeeds: 1. Assign the SAML app to all users in the IdP. 2. Communicate to the team: "From [date], sign in to Lido via [your IdP's app launcher]." 3. (Optional) Enforce SSO-only sign-in (see below). --- ## Enforce SSO (block password sign-in) By default, SSO is *additive* — users can still sign in with email/password if they have one set. To require SSO: 1. Lido SSO settings → **Enforce SSO**. 2. Confirm. After enforcement: - Email/password sign-in is blocked for workspace members. - Existing API keys keep working (API auth doesn't go through SSO). - Workspace owners can override emergency access (see "Lockout recovery" below). **Enforce only after** you've confirmed every active member can sign in via SSO. A misconfiguration here locks out the team. --- ## Provisioning (SCIM) If your IdP supports SCIM for automated user provisioning/deprovisioning, contact sales — Lido's SCIM integration is configured per-customer. Without SCIM, users are auto-created in Lido on first SSO sign-in (Just-In-Time provisioning) and removed manually from the Lido Members list when they leave. With SCIM, your IdP pushes user create/update/delete to Lido automatically. --- ## Group-to-role mapping If your IdP sends a `groups` attribute, you can map specific groups to Lido roles. Example: | IdP group | Lido role | | --- | --- | | `lido-admins` | Admin | | `lido-users` | Editor | | `lido-viewers` | Viewer | Configure mapping in Lido SSO settings. Users in multiple groups get the highest applicable role. --- ## Lockout recovery If SSO breaks (cert expired, IdP outage, misconfiguration) and no one can sign in: 1. Workspace **Owners** can sign in via a backup link sent to the owner's verified email. (Enable this in SSO settings BEFORE you'll need it.) 2. If even that fails, contact Lido support — emergency disable of SSO requires identity verification. **Strong recommendation:** keep at least one workspace owner with the backup email path enabled, separate from the SSO flow. --- ## Tips - **Test in incognito** to avoid existing session state masking misconfigurations. - **Map at least email**; everything else is optional but improves the user experience. - **Set the IdP cert expiration date in your team calendar.** Expired certs silently break SSO. - **Use SCIM if you have >50 users.** JIT provisioning is fine for small teams; manual deprovisioning is a security gap at scale. - **Document the recovery path.** "If SSO breaks, do X" should be in your IT runbook before you flip Enforce. - **Start with non-Enforce mode.** Roll out SSO gradually; flip to Enforce only after a stable week. --- ## Common mistakes - **Enforcing SSO before testing with a non-admin user.** Locks out the workspace. - **Wrong Entity ID or ACS URL.** SAML response fails with a confusing error. Copy-paste exactly from Lido. - **Missing email attribute** in the IdP attribute mapping. User signs in but Lido can't match them to an account. - **Cert mismatch.** When your IdP rotates its signing cert, update the metadata in Lido. Use the metadata URL (auto-refresh) when possible. - **No backup admin path.** The day SSO breaks, you'll wish you'd set this up. - **Forgetting that API keys bypass SSO.** SSO doesn't protect API access — rotate API keys when employees leave, regardless of SSO setup. --- ## Related articles - Security and data handling - Workspaces and user management - Lido API: quickstart and authentication (key rotation) - Pricing, plans, and page allowance (SSO is Enterprise)