VeritomeHelp Centre
/
Browse documentation
Integrations

Set up SSO and SCIM provisioning

Connect your identity provider over OIDC for single sign-on, and mint SCIM tokens so your IdP provisions and deactivates users automatically — both Enterprise features, configured by an Admin.

Updated Veritome documentation

Both features live under Organisation → SSO & SCIM and can only be configured by an organisation Admin. Single sign-on and SCIM provisioning are Enterprise features: on other plans the section shows what it does and stays read-only.

Single sign-on (OIDC)

Veritome supports OIDC single sign-on with providers such as Okta, Azure AD (Entra ID) or Google Workspace. SAML is not supported today.

  1. In your IdP, create an OIDC application and register the Redirect / callback URL shown at the top of the SSO section.
  2. In Veritome, enter the Issuer URL (must be https — the OIDC discovery document is fetched and validated when you save, so a bad issuer is caught before the connection is enabled), the Client ID and the Client secret. The secret is stored AES-256-GCM encrypted and is never shown again; leave the field blank on later edits to keep the current one.
  3. Add Allowed email domains (one per line). Members whose email domain matches sign in via SSO; password login stays available.
  4. Optionally enable auto-provision and pick the default role for new SSO users (Viewer by default).
  5. Turn the connection on. It is disabled by default, so configuring it can never disrupt existing logins.

SCIM provisioning

The SCIM section shows your SCIM 2.0 base URL (the /api/scim/v2 endpoint, with Users, Groups and ServiceProviderConfig resources). To connect your IdP:

  1. Create a SCIM token. The full token (starting with scim_) is shown exactly once — only its SHA-256 hash is stored, so copy it immediately.
  2. In your IdP, configure SCIM with the base URL and the token as the bearer token.
  3. When the IdP deactivates a user, their Veritome access is revoked.

Revoke tokens any time from the same section; every change is written to the audit log. Multi-factor authentication for password sign-in is separate and lives under Organisation → Security.