You can now require dashboard members to sign in through your own identity provider. SSO governs dashboard login only, over SAML 2.0 or OIDC. API keys authenticate programmatic requests on a separate path and are unaffected, so an SSO problem can never touch your production traffic.
To enable it, contact us with the email domains you want to govern. Only users whose email matches an approved domain fall under your connection, so a member signing in as [email protected] is in scope and a contractor on [email protected] is not. An admin then selects your provider under Organization to SSO. Okta, Entra ID, Google, Auth0, ADP, and others are supported out of the box, with Custom SAML and Custom OIDC for anything not listed.
Every assertion we accept carries four required attributes, which you map during setup:
{ "email": "email", "firstName": "firstName", "lastName": "lastName", "idpId": "NameID" }
How assertion fields map to Linq user fields. A missing or misnamed attribute rejects the login.
Two settings control enforcement. Allow non-SSO logins keeps existing methods available during rollout. Enforce SSO-only requires every member from an approved domain to authenticate through your IdP. Turning on enforcement logs out existing non-SSO sessions immediately, so if 200 people are working when you flip it, all 200 non-SSO sessions drop at once. Run Test sign-in first.
Two things to watch. Your signing certificate expiry is shown in the dashboard, and every SSO login fails the moment it lapses, so rotate ahead of the date. After any metadata or certificate change on the IdP side, re-run Test sign-in before relying on the connection. The Sessions list logs each attempt with email, name, status, and timestamp when you need to diagnose a failure.
Read the full guide in the SSO docs.
