SSO & SCIM. Enterprise identity, zero friction.

Elido uses WorkOS as the SSO and SCIM broker, which supports Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate, Shibboleth, ADFS, JumpCloud, and any SAML 2.0-compliant IdP. OIDC connections are also supported for providers like Google Workspace and Azure. If your IdP is not on the WorkOS standard list, WorkOS's 'Generic SAML' connection type works with any SAML 2.0 SP-initiated flow. Contact us if you need a specific IdP connection not listed.

JIT (Just-in-Time) provisioning creates a user account in Elido on their first SSO login — no pre-provisioning required. It's simpler to set up but gives no control over who can log in (anyone with a valid SSO assertion gets an account). SCIM provisioning gives your IdP control: only users in the provisioned group can log in, and accounts are created before first login. For enterprise environments where access must be pre-approved, SCIM is required. When SCIM is active, JIT provisioning is disabled.

In workspace SSO settings, you map your IdP groups to Elido roles: e.g., 'Okta group: Elido Admins' → 'Elido role: Admin', 'Okta group: Elido Members' → 'Elido role: Member'. A user's role in Elido follows their IdP group membership — if they're moved from the Admins group to the Members group in Okta, their Elido role is downgraded on next SCIM sync (typically under 60 seconds). A user in multiple groups takes the highest-privilege role from the matching mappings.

SSO can be set to enforced (all users must sign in via SSO — password sign-in is disabled) or optional (users can choose SSO or email+password). On Business, enforcement is configured in workspace SSO settings. Once enforced, users who don't have an active SSO identity are locked out — ensure SCIM provisioning or JIT has seeded accounts before enabling enforcement. Admin accounts can be exempt from SSO enforcement as a break-glass mechanism; this is configurable.

When SCIM deactivates a user, Elido suspends all API keys that were created by that user. Suspended keys return HTTP 401 on authentication. Keys are not deleted — they remain visible to workspace admins for audit purposes, with a 'suspended — offboarded user' status label. If a service account was using a personal API key (not a workspace service key), the key suspension will break that integration — this is intentional. For production integrations, use workspace-level service keys rather than user API keys.

SSO and SCIM are Business-only features. Pro workspaces use Elido's built-in authentication (email + password via Ory Kratos, optional Google/GitHub OAuth). If SSO is a hard requirement for your procurement approval, the Business plan is the starting point.

Each Elido workspace has its own SSO configuration — if you run multiple workspaces (e.g., per brand, per business unit), each gets its own IdP connection and SCIM provisioning separately. Users can be members of multiple workspaces with different roles in each; their IdP identity is the same, but group-to-role mappings are evaluated per workspace. A shared Okta group can map to Admin in one workspace and Member in another.

Yes. Failed SSO attempts (invalid SAML assertion, expired session, missing SCIM account when JIT is disabled) are logged in the workspace audit trail with the reason code. This is useful for diagnosing why a specific user can't log in and for detecting brute-force SSO probing. Failed attempts from IP addresses that exceed a threshold trigger a workspace alert (configurable in workspace security settings).