Skip to content
Helpdesk / Administration

Single sign-on (SSO) setup

Published May 23, 2026

Kommit supports SSO via SAML 2.0 and OIDC for Build, Enterprise, and Founding-customer tiers. Govern tier customers can use Google Workspace sign-in directly, but the SAML/OIDC IdP integration is a paid feature.

What SSO does

  • —Users sign in via your identity provider instead of a Kommit password.
  • —Membership in Kommit is gated on membership of a specific IdP group (configurable).
  • —De-provisioning in the IdP de-provisions Kommit access at the next session expiry (or immediately, with SCIM provisioning enabled — see "SCIM" below).

Supported IdPs

We've tested SSO end-to-end with:

  • —Okta (SAML + OIDC + SCIM)
  • —Azure Entra ID / Microsoft Entra (SAML + OIDC + SCIM)
  • —Google Workspace (SAML + OIDC; SCIM via partner connector)
  • —JumpCloud (SAML + OIDC)
  • —OneLogin (SAML + OIDC)
  • —Auth0 (OIDC)
  • —Generic SAML 2.0 IdP (any spec-compliant IdP should work; we test on request)

If your IdP isn't in this list, tell us at intake. Anything SAML 2.0 spec-compliant will work; we just want to verify before contracting.

Setup flow

Once your tier supports SSO:

  1. —Owner → Settings → SSO → New SSO connection.
  2. —Choose SAML or OIDC.
  3. —Kommit gives you the metadata it needs the IdP to know (ACS URL, entity ID, signing cert pubkey for SAML; redirect URI for OIDC).
  4. —You configure the connection on the IdP side.
  5. —Paste the IdP's metadata back into Kommit (XML for SAML, the discovery URL for OIDC).
  6. —Pick a default role for users who arrive via SSO (defaults to Member, same reasoning as [#inviting-teammates]).
  7. —Save. Kommit runs a connection test; if the IdP returns a valid assertion, SSO is live.

The connection test does not consume a real user; it uses a self-issued assertion against the IdP's metadata. If the test fails, the error message will tell you which part of the configuration didn't match.

Per-user behaviour after SSO is live

  • —Existing users with Kommit passwords continue to work until you flip "Enforce SSO" on. That setting blocks password sign-in org-wide; recommend turning it on once you've verified at least two Owners can sign in via SSO (so you don't lock yourself out).
  • —New users sign in via SSO only. Their first sign-in creates their Kommit account with the default role from step 6.
  • —Users provisioned via SCIM appear in Kommit immediately on IdP-side group assignment.

SCIM

SCIM 2.0 provisioning is available on Enterprise and Founding-customer tiers. Setup is similar to SSO — Kommit gives you a SCIM endpoint URL and a bearer token, you configure your IdP's provisioning rules, and on save Kommit syncs your IdP's user state into Kommit on a schedule (default 5 minutes; can be made event-driven via your IdP's push API).

SCIM-provisioned users cannot be removed from the Members page in Kommit — they're managed by the IdP. To remove a SCIM user, remove them from the IdP group.

Troubleshooting

  • —"Assertion failed signature verification" — the SAML signing cert in Kommit doesn't match what the IdP is using. Re-paste the IdP's metadata.
  • —"Email mismatch" — the SAML assertion's NameID or the OIDC token's email claim doesn't match the email the user signed up with. Update your IdP's claim mapping, or have the user use the "merge accounts" flow in Settings.
  • —"No matching group" — the user authenticated but isn't in the IdP group you said gates Kommit access. Add them to the group and have them re-attempt sign-in.

For anything else, security@getkommit.ai is the fastest path.