This page covers OIDC-based SSO authentication to the DB Console. For SSO authentication to the SQL interface using JSON Web Tokens (JWT), refer to . For LDAP-based authentication (which also supports DB Console login), refer to .
Configuration
Prerequisites
- IdP: You must have access to an OAuth 2.0 identity provider and client. Refer to Step 1: Provision an OIDC client.
-
CockroachDB cluster: You must have access to one of the following:
- A self-hosted cluster enabled with a valid .
- A .
CockroachDB Standard and Basic clusters do not have access to the DB Console. For SQL client authentication on these tiers, refer to .
Step 1: Provision an OIDC client
These steps demonstrate how to create an OIDC auth client in Google Cloud Platform to use for SSO authentication to the DB Console.- Open the Credentials page for your account at Google APIs.
- Click + CREATE CREDENTIALS and select OAuth client ID. Specify a web application from the pulldown menu.
- Note the client ID and client secret of the OAuth 2.0 client: you will need to configure your cluster to use these values.
-
Add your cluster’s callback URL to the list of Authorized redirect URIs. On a local cluster, this will be
https://{ your cluster's domain }:8080/oidc/v1/callback. Subsequently, when configuring your cluster, you will need to ensure that the cluster settingserver.oidc_authentication.redirect_urlhas the same value.- For a self-hosted cluster, the domain is
localhost. - For an Advanced cluster, open the DB Console from the cluster’s Tools tab in the Cloud Console, and use the host portion of that URL as your domain.
- For a self-hosted cluster, the domain is
Step 2: Configure cluster settings
You must have the required privileges to update your cluster settings. Refer to .Cluster settings
Configure the in the following table to enable SSO authentication to the DB Console. Refer to Update your cluster settings.Update your cluster settings
Open a SQL shell to your cluster:https://localhost:8080/oidc/v1/callback. For a Advanced cluster, replace localhost with your cluster’s domain, which can be found by opening the DB Console from the Tools tab in your cluster’s page in Cloud Console.
openid scope (required) and the email scope (needed when using email as the claim key):
email field from the ID Token:
email that you can match to a SQL user. For example, '^([^@]+)@cockroachlabs\.com$' extracts the characters that precede @cockroachlabs.com in the email address.
Step 3: Configure user creation
CockroachDB supports two approaches for the creation of users who will authenticate via OIDC:Option 1: Automatic user provisioning (recommended)
With automatic user provisioning, CockroachDB creates users automatically during their first successful OIDC authentication. This eliminates the need for custom scripting to create user accounts. To enable automatic user provisioning:Enabling automatic user provisioning may introduce latency during periods of concurrent OIDC authentication attempts from multiple browsers. This is because CockroachDB must check for user existence before provisioning, which generates read request load on the
system.users table.- Users are created automatically upon successful OIDC authentication.
- All auto-provisioned users receive a
PROVISIONSRCrole option set tooidc:{provider_url}. - The
estimated_last_login_timecolumn in theSHOW USERSoutput is updated for DB Console logins, enabling tracking of user activity for auditing and identifying dormant accounts. - Auto-provisioned users cannot change their own passwords (managed via OIDC only).
Before you enable automatic user provisioning, it is recommended that you enable . This ensures that upon initial login, new CockroachDB users are members of the intended CockroachDB roles, with the privileges they confer, according to users’ group memberships in the identity provider. Otherwise, functionality may be limited for a new user until your alternative process applies roles or privileges.If you choose to manage CockroachDB role memberships and privileges directly, you could script the required commands to be as needed.
Option 2: Manual/scripted user creation
You can manage users by directly creating them before OIDC authentication is used. This approach provides explicit control over user creation. To create a single user:principal_regex from the OIDC token. For example, if you configured claim_json_key = 'email' and principal_regex = '^([^@]+)@cockroachlabs\.com$', a user with the email address docs@cockroachlabs.com will need the SQL username docs.
Step 4: Enable OIDC authentication
Log in to a cluster’s DB Console with SSO
From the user’s perspective, once the cluster is properly configured to an identity provider, the sign-in flow is as follows:- A user opens the cluster’s DB Console, and clicks the Log in with your OIDC provider button on the page.
- The user is redirected to an external identity provider.
- The user authenticates successfully with the provider, which completes the OAuth flow.
- The user is redirected to the CockroachDB cluster.
- CockroachDB creates a web session for the SQL user in a new browser tab.
- In the original browser tab, the user is redirected to the DB Console page.
Manage auto-provisioned users
When automatic user provisioning is enabled, you can identify and manage auto-provisioned users as follows:View provisioned users
Auto-provisioned users can be identified by theirPROVISIONSRC role option:
PROVISIONSRC=oidc:{provider_url} in their options column.
Last-login tracking for usage and dormancy
Theestimated_last_login_time column in the SHOW USERS output tracks when users last authenticated. This can help identify dormant accounts that may need review or removal.
estimated_last_login_time is computed on a best-effort basis and may not capture every login event due to asynchronous updates.Clean up users removed from the identity provider
Auto-provisioned users who have been removed or deactivated in your identity provider will not be automatically removed from CockroachDB. To identify and clean up these orphaned accounts:Step 1: Export auto-provisioned users from CockroachDB
Step 2: Cross-reference with your identity provider
Use your organization’s identity management tools to verify which of these users still exist in your IdP. The specific method depends on your identity provider (Okta, Google Workspace, Azure AD, etc.).Step 3: Remove orphaned users
Before dropping users confirmed to no longer exist in your identity provider, check for any privileges that were granted directly to the user:Users cannot be dropped if they have direct privilege grants or own database objects. For complete requirements, refer to . When using both automatic user provisioning and OIDC authorization, consider granting privileges primarily through roles (mapped to IdP groups) rather than directly to users to simplify cleanup operations.
Restrictions on auto-provisioned users
Users created through automatic provisioning have specific restrictions:- Password changes: Auto-provisioned users cannot change their own passwords using
ALTER USER, even if the cluster settingsql.auth.change_own_password.enabledis true. - PROVISIONSRC modification: The
PROVISIONSRCrole option cannot be modified or removed once set. - Authentication method: These users must authenticate through OIDC; password-based authentication is not available.

