Articles on: Compliance & security

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.




  • Security and data handling
  • Workspaces and user management
  • Lido API: quickstart and authentication (key rotation)
  • Pricing, plans, and page allowance (SSO is Enterprise)

Updated on: 16/04/2026

Was this article helpful?

Share your feedback

Cancel

Thank you!