Enterprise SSO.

Connect your OIDC identity provider so your team signs in to Vericto with corporate credentials: automatic provisioning, verified domains, and enforced SSO access.

Overview

Single Sign-On (SSO) lets your team access Vericto using your organization's identity provider, without managing separate passwords for each person. Vericto works with any standard OIDC provider, so you can centralize access in the same tool you already use for the rest of your applications.

Once configured, users from your verified domains sign in with a single click. You can provision accounts automatically, assign a default role, and, if needed, require the entire team to sign in exclusively via SSO.

SSO is an Enterprise plan feature. Only the workspace owner can enable and modify it. Changes to the SSO configuration take effect immediately for the whole team.

Prerequisites

Before setting up SSO, make sure you meet the following:

  • Enterprise plan: enterprise SSO is available only on the Enterprise plan. If your workspace is on another plan, upgrade first.
  • Owner role: only the workspace owner can enable, edit, or disable SSO. The internal capability that governs it is sso.manage.
  • An OIDC identity provider: you need administrator access to your provider (Okta, Microsoft Entra ID, Google Workspace, Auth0, or any standard OIDC) to create an application and obtain its credentials.
  • Control of the email domain: to verify your organization's domains you need to be able to create a DNS TXT record in each domain's zone.

Store the client secret securely. Vericto stores it encrypted and does not display it in full again after saving. If you lose it, generate a new one in your provider and update it in the configuration.

Step-by-step setup

The configuration lives in Dashboard → Settings → SSO. A four-step wizard guides you from choosing the provider to activating the connection:

Step 1: Provider

Choose the identity provider and enter a provider name. This name is just a descriptive label for your team (for example, "Corporate Okta") and appears on the sign-in button.

Step 2: Credentials

Enter the credentials you obtained when creating the OIDC application in your provider:

  • Issuer URL (OIDC): the provider's base URL that exposes its discovery document, for example https://your-org.okta.com.
  • client_id: the public identifier of the application you created in your provider.
  • client_secret: the secret associated with that application. It is stored encrypted.

Step 3: Behavior

Define how the connection behaves: enable or disable JIT provisioning, choose the default role for provisioned users, and decide whether to enforce SSO. You will find the details of these options in the next section.

Step 4: Domains

Add and verify your organization's email domains. Only users from verified domains can use SSO. See the domains section for the DNS verification process.

The connection is not operational until you enable the connection active toggle. You can save the configuration, verify the domains, and activate the connection when you are ready for the cutover.

Domains and DNS verification

Email domains define which users can sign in via SSO. A domain must be in the verified state for Vericto to accept sign-ins from addresses in that domain. The verification process proves that you control the domain:

  1. In the Domains step, add an email domain (for example, company.com). It stays in the pending state.
  2. Vericto generates a verification token that you can copy. Create a DNS TXT record with that token in the domain's zone.
  3. Once the DNS record has propagated, click verify. Vericto checks the TXT record and, if it matches, the domain moves to the verified state.
  4. You can remove a domain at any time. When you do, users from that domain can no longer authenticate via SSO.

DNS propagation can take from a few minutes to several hours depending on your provider. If verification fails, wait and try again: the token does not change while the domain remains in the pending state.

JIT provisioning, default role, and enforce SSO

JIT provisioning

With JIT provisioning (just-in-time provisioning) enabled, any user from a verified domain who signs in via SSO automatically joins the workspace, with no need for a manual invitation. The account is created on the first sign-in and is assigned the default role you configure.

Default role

The default role determines the permissions with which JIT-provisioned users join. You can choose between:

  • member: read access to the dashboard, queries, and audit trail. This is the recommended option for most teams.
  • viewer: read-only access to the dashboard and audit trail. Suitable for stakeholders or auditors.
  • admin: management of databases, rules, API keys, and the team. Use it with caution as a default role.

After the first sign-in, an owner or admin can adjust any user's role individually from the team.

Enforce SSO

The enforce SSO toggle requires all workspace users to sign in exclusively through SSO and disables access with email and password. It is the recommended configuration for organizations that require a single point of access and identity control.

Verify access before enabling enforce SSO. Confirm that the connection works and that at least one owner can sign in via SSO. If you enable enforce SSO with an incorrect configuration, you could lock the team out. Keep the support contact handy in case you need to restore password login.

Frequently asked questions

Which identity providers are supported?

Any standard OIDC provider. Okta, Microsoft Entra ID, Google Workspace, and Auth0 are explicitly validated, but it works with any provider that exposes a standards-compliant OIDC issuer.

Can I use SSO without JIT provisioning?

Yes. If you disable JIT provisioning, users can authenticate via SSO but only if they are already part of the team. In that case you still invite people manually and SSO is used only as a sign-in method.

Who can configure SSO?

Only the workspace owner, on an Enterprise plan. Admins can manage the rest of the team, but the SSO configuration is reserved for the owner through the sso.manage capability.

What happens if I disable the connection?

If you disable the connection active toggle, SSO sign-ins stop working. If you did not have enforce SSO enabled, existing users can sign back in with email and password. With enforce SSO enabled, disable enforce SSO first so you do not lock out the team.

Do I need to verify a domain for each subdomain?

Yes. Each email domain is verified independently with its own DNS TXT record. If your team uses several domains, add and verify each one separately.