Single sign-on (SAML, OpenID Connect and SCIM)

Connect your company's identity provider (IdP) to a Logthread workspace so people sign in with their work account, get the right role from their groups, and lose access the moment they leave. Everything is set up by a workspace owner in Settings → Single sign-on; nothing needs Logthread support.

Single sign-on and SCIM are part of the Growth and Enterprise plans. "Continue with Google" and "Continue with Microsoft" on the sign-in page are separate and available on every plan.

How it works#

1. Verify a domain. Add example.com and publish the TXT record Logthread shows: name _logthread-challenge.example.com, value logthread-verification=…. Press Verify. Only addresses in a verified domain can sign in through SSO, be created just in time or be provisioned with SCIM, and a domain can be verified by one workspace only. Public mailbox domains such as gmail.com cannot be verified.
2. Connect your identity provider with SAML 2.0 or OpenID Connect (OIDC). The page shows the values your IdP needs and a guide for Okta, Microsoft Entra ID, Google Workspace, OneLogin and JumpCloud (below).
3. Test connection. You sign in at the IdP and Logthread shows exactly what came back (subject, email, name, groups) or why it was refused. Testing never signs anyone in.
4. Turn single sign-on on. It needs a passing test with the current settings; changing an IdP setting needs a new test before you can enforce.
5. Optionally require it (see Enforcement).

People sign in from the sign-in page with Sign in with SSO (by work email or your sign-in link name), from your bookmarkable link https://logthread.com/sso/<name>, or from the IdP's app dashboard (IdP-initiated SAML, which you can turn off).

Logthread values for your identity provider#

Copy the exact values from the page: the connection id is created when you choose SAML or OIDC.

What Logthread checks#

• SAML: the response must be signed (the assertion, the response or both) with the certificate you configured, using SHA-256 or stronger. Logthread checks the audience, the recipient (ACS URL), the issuer, the validity window (90 seconds of clock skew), that the response answers a sign-in this browser started, and that an assertion is used only once. Encrypted assertions are not supported: leave assertion encryption off in the IdP. You can store up to three certificates during a rotation.
• OIDC: issuer discovery, the authorization code flow with PKCE, state and nonce, and the ID token's signature, issuer, audience and age. The client secret is stored encrypted and never shown again.

Roles and just-in-time accounts#

• Just in time: with it on, a person from a verified domain who signs in for the first time gets an account and joins the workspace. With it off, only existing members and SCIM-provisioned people can sign in.
• Default role: Viewer, Member or Admin.
• Group → role mapping: map IdP group names (or IDs, for Entra) to Viewer, Member or Admin. The highest match wins and is applied again at every sign-in and on SCIM group changes. Owners are never changed by SSO or SCIM, and SSO never grants Owner. What each role can do, in the app and through MCP, is on Roles and permissions.
• An existing Logthread account with the same email is linked, because the verified domain makes your IdP authoritative for those addresses.

Enforcement and sessions#

• Require SSO: members can only reach the workspace through your IdP; password and Google / Microsoft sign-in stop working for it. Owners keep password access for emergencies (break-glass), and every such sign-in is written to the audit log as sso.break_glass.
• SSO session lifetime (1 hour to 30 days): after it, people go through the IdP again.
• Sign everyone out ends every session that came through SSO, for example after changing mappings.
• If the workspace leaves the Growth or Enterprise plan, the configuration is kept but SSO sign-in and SCIM stop and enforcement is lifted, so nobody is locked out.

SCIM provisioning#

Generate a token in SCIM provisioning (it is shown once) and give the IdP the base URL and the token as a bearer token. Logthread supports Users and Groups with filtering and PATCH in the forms Okta and Entra send. Users must have an address in a verified domain. Deactivating a user removes them from the workspace and ends their sessions and the API keys they created at once; reactivating restores them with their mapped role. Owners cannot be deactivated through SCIM. Up to five tokens can be active.

Okta#

SAML

1. In the Okta Admin Console open Applications → Applications → Create App Integration, choose SAML 2.0 and name the app Logthread.
2. Single sign-on URL: the ACS URL. Keep "Use this for Recipient URL and Destination URL" checked.
3. Audience URI (SP Entity ID): the entity ID.
4. Name ID format: EmailAddress. Application username: Email.
5. Optional: add a group attribute statement named groups (filter "Matches regex" .*).
6. Finish, open the Sign On tab and copy the Metadata URL. Paste it under Import IdP metadata in Logthread.
7. Assign people or groups, then run Test connection.

OIDC: Create App Integration → OIDC - OpenID Connect → Web Application; sign-in redirect URI = the redirect URI; grant type Authorization Code. Copy the client ID and secret. Issuer: https://<your-okta-domain>/oauth2/default. Optional: Sign On tab → OpenID Connect ID Token → Groups claim filter groups, "Matches regex" .*.

SCIM: in the SAML app set General → App Settings → Provisioning to SCIM. On Provisioning → Integration enter the SCIM base URL, unique identifier field userName, actions Push New Users, Push Profile Updates and Push Groups, authentication HTTP Header with the Logthread token. Test, save, and under To App enable Create Users, Update User Attributes and Deactivate Users. Push the groups you map to roles.

Microsoft Entra ID#

SAML

1. In the Microsoft Entra admin center open Enterprise applications → New application → Create your own application (non-gallery), named Logthread.
2. Single sign-on → SAML. Basic SAML Configuration: Identifier (Entity ID) = the entity ID, Reply URL (ACS) = the ACS URL.
3. Attributes & Claims: set the Unique User Identifier (Name ID) to user.mail with the Email address format.
4. Optional: Add a group claim (groups assigned to the application). Entra sends group object IDs unless you choose cloud-only display names; map whichever value it sends.
5. SAML Certificates: copy the App Federation Metadata Url and import it in Logthread.
6. Users and groups: assign who may sign in, then run Test connection.

OIDC: App registrations → New registration, platform Web, redirect URI = the redirect URI. Certificates & secrets → New client secret. Issuer: https://login.microsoftonline.com/<tenant-id>/v2.0. Token configuration: add the email optional claim to the ID token, and a groups claim if you map groups.

SCIM: in the enterprise application open Provisioning → Get started, mode Automatic. Tenant URL = the SCIM base URL, Secret Token = a Logthread token. Test Connection and save. Keep userName mapped to userPrincipalName (or mail) in a verified domain. Start provisioning; Entra syncs about every 40 minutes, and Provision on demand tests one user.

Google Workspace#

1. In the Google Admin console open Apps → Web and mobile apps → Add app → Add custom SAML app, named Logthread.
2. Save the IdP metadata file and paste its XML under Import IdP metadata in Logthread (or copy the SSO URL, entity ID and certificate).
3. Service provider details: ACS URL and Entity ID from Logthread. Name ID format EMAIL, Name ID Basic Information → Primary email.
4. Optional: attribute mapping Group membership → groups.
5. User access: turn the app ON for everyone or the right organizational units, then run Test connection (changes can take a few minutes).

Google Workspace cannot provision custom apps over SCIM: use just-in-time accounts, and remove people in Logthread (or with group mapping) when they leave.

OneLogin#

SAML: Applications → Add App → SAML Custom Connector (Advanced), named Logthread. On Configuration: Audience (EntityID) = the entity ID; Recipient and ACS (Consumer) URL = the ACS URL; ACS (Consumer) URL Validator = the ACS URL with dots escaped. SAML nameID format Email, SAML signature element Assertion (or Both). Optional: Parameters → groups, "Include in SAML assertion", multi-value, from User Roles or MemberOf. On the SSO tab copy the Issuer URL (the metadata URL) and import it. Assign users and run Test connection.

OIDC: Applications → Add App → OpenId Connect (OIDC); redirect URI = the redirect URI; on SSO copy the client ID and secret (token endpoint authentication Basic or POST). Issuer: https://<subdomain>.onelogin.com/oidc/2.

SCIM: use the SCIM Provisioner with SAML (SCIM v2 Enterprise) connector for the Logthread app (with the SAML settings above). SCIM Base URL and SCIM Bearer Token = the Logthread values; enable provisioning on the Provisioning tab. Delete and Suspend both deactivate in Logthread.

JumpCloud#

SAML: SSO Applications → Add New Application → Custom Application → Manage Single Sign-On (SSO) → Configure SSO with SAML. SP Entity ID = the entity ID; ACS URL = the ACS URL; IdP Entity ID = any unique name such as jumpcloud-logthread. SAMLSubject NameID email, format emailAddress, signature algorithm RSA-SHA256, sign the assertion. Optional: include the group attribute named groups. Save, Export Metadata and paste the XML into Logthread. Bind user groups and run Test connection.

OIDC: Custom Application → Configure SSO with OIDC; redirect URI = the redirect URI; client authentication Client Secret Basic. Issuer: https://oauth.id.jumpcloud.com/. Map email, and groups if you map groups.

SCIM: in the application open Identity Management → SCIM 2.0: Base URL = the SCIM base URL, Token Key = a Logthread token. Test Connection, Activate, and enable Group Management for the groups you map.

Troubleshooting#

Test connection names the problem. The common ones:

Every configuration change, test, sign-in, refused sign-in, break-glass sign-in and SCIM change is recorded in Administration → Audit log.

Next: let AI agents work with your data through MCP.