Appearance

Identity Providers ​

What's on this screen ​

The Identity providers panel lets a Vibedata Owner or User Access Administrator register the OAuth/OIDC applications that serve this deployment. Each provider can sign users in to Vibedata, serve Domain and Secret Store delegation, or both — an Allow sign-in setting on the provider decides which. The panel supports registering new Microsoft Entra ID, Generic OIDC, Snowflake and Databricks providers. A Google Workspace or GitHub sign-in provider configured before this panel existed keeps working and appears in this list; it is not something you can register fresh from this screen.

How to add a provider ​

  1. Open Org Settings and select Identity providers.
  2. Click Add identity provider.
  3. Choose Microsoft Entra ID or Generic OIDC from Provider type.
  4. Fill in Display name.
  5. Copy the read-only Callback URL into the provider's application registration.
  6. Fill in Tenant ID for Microsoft Entra ID or Issuer URL for Generic OIDC.
  7. Fill in Client ID.
  8. Fill in Client secret.
  9. Leave Allow sign-in selected so the provider can sign users in to Vibedata, or clear it to register a delegation-only provider that only serves Domains and never signs anyone in.
  10. Select Automatically approve new users when users who first sign in through this provider (when sign-in is allowed) should enter Vibedata without manual approval.
  11. Click Create. Vibedata returns to the provider list and shows the saved provider as Pending test.
  12. Open the provider from the list, then click Test on its item page. A successful connection test activates the provider automatically.

For Microsoft Entra ID, configure the Entra app registration to include the optional ID-token claim email_verified when users need same-email linking across multiple Vibedata providers. Without that claim, Entra sign-in can still work for its own provider account, but Vibedata will not use the Entra email claim to link into an existing user from another provider.

How to register a Snowflake provider ​

A Snowflake provider is delegation-only: it lets users connect their own Snowflake account so Domains run as them. It never signs anyone in to Vibedata, so it has no Allow sign-in or Automatically approve new users setting.

  1. Ask a Snowflake account administrator to create an OAuth security integration. In the registration form, open Set up the Snowflake security integration to see the settings it needs: a confidential custom client, the Callback URL as its redirect URI, refresh tokens issued, OAUTH_ANY_ROLE_MODE set to ENABLE_FOR_PRIVILEGE with the USE_ANY_ROLE privilege granted, OAUTH_USE_SECONDARY_ROLES set to IMPLICIT, and an access-token validity of 3600.
  2. Choose Snowflake from Provider type and fill in Display name.
  3. Fill in Account identifier as <organization>-<account>.
  4. Fill in Account host only if the account is reached through private connectivity. It must end in .snowflakecomputing.com.
  5. Fill in Integration name, Client ID and Integration client secret. The secret is stored encrypted and never shown again; select the reveal button inside the field to read back what you typed before saving.
  6. Click Create, then open the provider from the list and click Test on its item page. Test signs in once, refreshes the credential, and proves a session can take another role.

The account identifier, host and integration name cannot be changed after saving. To rotate the secret, edit the provider and enter the new Integration client secret; leave it blank to keep the stored one.

A passing Test can still show warnings: refresh tokens valid for less than 7 days (every user reconnects at least weekly) and access tokens valid for under 300 seconds. A Test that fails with the role-switch message means the integration does not let a session take another role; the message names the setting and the grant an administrator must change.

Once a user connects their Snowflake account, the agent works in their Snowflake session: it queries, loads (dlt) and builds (dbt) as that user, in the Intent's own database and with the Intent's own role, and every statement carries a query tag naming the Domain, Intent, user and tool. The agent never holds a Snowflake password or key. This reaches Intents with the agent image release that contains the Snowflake runtime; until then a Snowflake Intent cannot start an agent.

How to register a Databricks provider ​

A Databricks provider is delegation-only: it lets users connect their own Databricks account so Domains run as them. It never signs anyone in to Vibedata, so it has no Allow sign-in or Automatically approve new users setting. Databricks is the only way a person's own Databricks access reaches Vibedata, on Azure, AWS and GCP alike.

  1. Ask a Databricks account administrator to register a custom OAuth app at the account level (account console, Settings, App connections) with these settings:
    • Client type: confidential (Databricks generates a client secret).
    • Redirect URL: the read-only Callback URL shown in the registration form.
    • Scopes: exactly sql, unity-catalog, jobs, workspace, secrets and offline_access, and nothing else. jobs and workspace let the agent run its sandbox notebooks and jobs on Databricks as the user, and reach every Jobs, Workspace, Repos and Git-credential call the user's own permissions allow, deletes included. offline_access must be registered explicitly or Databricks refuses the connect.
    • Access-token lifetime: 60 minutes.
    • Refresh-token lifetime: 90 days is recommended. The default is 7 days, after which every user must reconnect.
  2. Choose Databricks from Provider type and fill in Display name.
  3. Fill in Account ID (the Databricks account UUID) and choose the account's Cloud.
  4. Fill in Client ID and Client secret from the app registration.
  5. Click Create, then open the provider from the list and click Test on its item page. Test signs in once and checks the granted scopes.

The account ID and cloud cannot be changed after saving. Register one provider per Databricks account; a user with several accounts connects each one separately from Connections. A Domain uses one Databricks provider, and its workspaces must belong to that account and be on the same cloud. AWS and GCP accounts become available once their live checks pass; until then only Azure Databricks accounts can be registered.

Register only those scopes. Databricks shows users every scope the app registers, not only those Vibedata asks for, and changing the app's scope set later prompts every user again.

Test failures:

  • databricks_scope_not_registered: the app is missing one of sql, unity-catalog, jobs, workspace, secrets or offline_access. Add it in the account console and run Test again.

What users see. Each user selects Connect on the Databricks connection in User settings → Data platforms and signs in to Databricks on the consent screen. The consent screen appears on first connect and again whenever the app's scope set changes.

  • Any Databricks login works. Vibedata links the Databricks user who signs in on the consent screen. Its user name does not have to match the user's Vibedata email, so a user who signs in to Vibedata with GitHub can connect a Databricks account from another tenant. The user checks that the Databricks account shown on the consent screen is the one they mean to connect, and signs out of Databricks (or uses a private window) first if another account is already signed in.
  • Reconnect after scope changes. A connection can only be used within the scopes granted when it was made. If Vibedata later needs a scope the connection lacks, the request fails with databricks_scope_not_granted and the user selects Reconnect. This happens only after a Vibedata release that widens the scope set.

The Domain's service principal. Scheduled and service runs use a Databricks-managed service principal created in the account console, not a person. Give it:

  • an OAuth secret with a lifetime of at most 730 days;
  • assignment to each bound workspace, with the Databricks SQL access entitlement;
  • CAN_USE on each SQL warehouse;
  • on the production catalog: USE CATALOG, USE SCHEMA and SELECT;
  • on the Ephemeral catalog: USE CATALOG and CREATE SCHEMA, without owning the catalog or holding MANAGE;
  • no workspace admin or metastore admin role.

The exact commands are in section 4 of the Databricks permissions proposal.

How to configure automatic approval ​

  1. Open Identity providers and click Add identity provider, or open an existing provider from the list.
  2. Select Automatically approve new users when users who first sign in through that provider should enter Vibedata without manual approval.
  3. Click Create.

Automatically approve new users is clear by default. It approves only accounts Vibedata records after you enable the setting; existing Pending approval users still require Approve under Org Settings → Users. Automatic approval does not grant platform roles or Domain memberships, and it has no effect on a provider with Allow sign-in cleared.

How to edit an active provider ​

  1. Open Identity providers and open the provider from the list.
  2. Change the provider values. Leave Client secret blank to keep the stored secret. Toggle Allow sign-in to change whether the provider may sign users in to Vibedata.
  3. Click Save. Vibedata stays on the item page; the existing active configuration keeps serving sign-ins and delegation while the replacement shows Active · changes pending test.
  4. Click Test. A successful test activates the replacement automatically. A failed or canceled test leaves the existing active configuration unchanged.

How to archive a provider ​

  1. Open Identity providers.
  2. Open the provider from the list.
  3. Click the archive icon in the item page header. Vibedata asks you to confirm, and names every Domain that references the provider, including Domains that use it only for their Secret Store or through connection reuse, in any lifecycle state. Archive is blocked only while an ACTIVE Domain references the provider; remove it from those Domains first.

Archiving clears the client secret; non-secret fields (client ID, tenant or issuer boundary, name) are retained. An archived provider has no dedicated Unarchive control: open its item page, fill in the now-empty, required Client secret, click Save, then Test — the same save-then-test path as a normal edit.

What you'll see ​

  • No identity providers registered — no provider rows exist.
  • Loading identity providers… — Vibedata is loading provider rows.
  • Unable to load identity providers. — the provider list failed to load; use Retry.
  • A provider with this name already exists for this kind. — choose a different display name; the callback URL is derived from provider type + display name and must stay unique.
  • Pending test — a new saved provider is pending its first Test and is not yet available for sign-in or delegation.
  • Active · changes pending test — an active provider has saved replacement values; sign-in and delegation continue on the existing active values until the replacement passes Test.
  • Test in progress / Active · replacement test in progress — a test is running for this provider.
  • Test failed · … / Active · replacement test failed · … — Test failed with a specific reason; the saved candidate remains available to edit or retry, and any existing active values stay live.
  • Active · Snowflake rejected the integration client ID or secret; save a new client secret / Active · Snowflake refused a token refresh; check the security integration and its refresh token validity — Snowflake refused the provider's credentials after it went active, and the row shows an error until the refusal clears. It clears when a later token refresh succeeds, or when a new client secret is saved and passes Test.
  • Archived — the provider is archived; open it from the list, fill in the required Client secret, and Save to bring it back.

Quick reference ​

ControlWhat it does
Provider typeSelects the kind for a new registration, for example Microsoft Entra ID or Generic OIDC.
Display nameSets the label shown for the provider row.
Tenant IDIdentifies a Microsoft Entra tenant.
Issuer URLIdentifies a Generic OIDC issuer.
Client IDStores the OAuth client id.
Client secretStores the encrypted OAuth secret.
Account identifierNames the Snowflake account (<organization>-<account>) for a Snowflake provider.
Account hostOptional private-connectivity host for a Snowflake provider.
Account ID / CloudName the Databricks account (a UUID) and its cloud for a Databricks provider; fixed after saving.
Integration nameNames the Snowflake OAuth security integration, shown in Test messages.
Integration client secretStores the Snowflake integration's encrypted client secret; replace it to rotate.
Allow sign-inLets this provider sign users in to Vibedata; clear it for a delegation-only provider. Defaults on.
Automatically approve new usersApproves new accounts from this provider after their first sign-in.
CreateCreates a new provider, then returns to the provider list.
SaveSaves edits on the provider's item page; Vibedata stays on the item page.
TestTests the saved candidate and activates it automatically on success.
ArchiveArchives the provider from its item page header, after confirming.