Adding the OAuth client ID and secret to a dbt connection

1.What the client ID and secret are for

With warehouse OAuth, dbt never stores a developer's warehouse password. Each developer signs in through the warehouse's own login or SSO. To make that work, the warehouse first has to recognise dbt as a trusted application. The client ID is the public name of that application. The client secret proves that a request really comes from dbt. Both are set once per connection, and every developer on the project uses them.

The work is split between two groups of people. An admin creates the OAuth application on the warehouse side, copies its client ID and secret, and pastes them into the dbt connection. Only after that can each developer complete their own authorization from their profile credentials. That second step is covered under [developer OAuth authorization](lesson:1.4). If the client credentials are missing from the connection, there is nothing for developers to authorize against.

Native OAuth is available on Enterprise and Enterprise+ plans. The setup docs cover Snowflake, Databricks and BigQuery. Snowflake and Redshift can also use an external identity provider. Each platform generates its client credentials differently and puts them in a different part of the dbt connection, and that difference is what the rest of this page is about.

Sources123

2.Snowflake: read the secret from the security integration

For Snowflake, the client ID and secret come from a Snowflake security integration. They are not created in a console screen. A Snowflake admin first creates an integration of TYPE = OAUTH, with dbt's redirect URI in it. The example integration is named DBT_CLOUD. Creating it takes privilege: only users with the ACCOUNTADMIN role, or a role with the global CREATE INTEGRATION privilege, can run that statement. The full statement and its fields are part of [developer OAuth authorization](lesson:1.4). For this lesson, what matters is that the integration now holds a client ID and secret.

To read them, run system$show_oauth_client_secrets against the integration name. The query below parses the JSON it returns into two columns, client_id and client_secret. The name you pass in must exactly match the name you gave the integration. If you pass a different name, you are querying the wrong integration, or one that doesn't exist.

with

integration_secrets as (
  select parse_json(system$show_oauth_client_secrets( ? )) as secrets
)

select
  secrets:"OAUTH_CLIENT_ID"::string     as client_id,
  secrets:"OAUTH_CLIENT_SECRET"::string as client_secret
from
  integration_secrets;

The Database Admin then enters the two values on the dbt side. Snowflake connections are an account-level resource, so the path starts in Account Settings → Connections:

1. Navigate to Account Settings, click Connections, and select the Snowflake connection. 2. Edit the connection and enter the Client ID and Client Secret. 3. Click Save.

After you save, developers on the project see a Connect to Snowflake Account button in their profile credentials. Clicking it sends them to Snowflake to authorize. If someone reports that the button is missing, check first whether the connection's client credentials were ever saved.

Sources2

3.Databricks: generate once, store under Optional settings

In Databricks, dbt is registered as a custom OAuth application. In the account console, open Settings → App connections → Add connection. Give the connection a name, the two redirect URLs for your dbt region, the access scopes, and token lifetimes. Then select Generate a client secret. That moment is the only chance to copy the secret, so put it straight into a secure store. Choose the scopes carefully too. SQL models need the SQL scope. Python models need the ALL APIs scope.

The values go in a different place than Snowflake's, and it's easy to miss. Open Account settings, select Projects, choose the project, click Connections, select the Databricks connection, and click Edit. The client ID and secret are not among the main connection fields. They go under the Optional settings section, as OAuth Client ID and OAuth Client Secret.

Sources4

4.BigQuery: an OAuth client plus a token URI

BigQuery's client credentials come from Google Cloud's APIs & Services → Credentials page. If an OAuth consent screen doesn't exist yet, set one up first. Then click + Create Credentials, choose OAuth client ID, and select the Web application application type. Under Authorized redirect URIs, add the redirect URI copied from the dbt connection. Authorized JavaScript origins aren't used.

Unlike Databricks and Entra ID, Google doesn't hide the secret after creation. If you close the app screen, the values are still there to copy later. Back in dbt, open the BigQuery connection's details and add the client ID and secret under the OAuth 2.0 Settings section. BigQuery also asks for one more field than the other platforms: the token URI, which defaults to https://oauth2.googleapis.com/token. You don't need to configure scopes on the consent screen. dbt requests the scopes it needs while each user authenticates.

Sources3

5.External OAuth: credentials live in an integration, not the connection

With external OAuth, the client ID and secret come from an outside identity provider rather than from the warehouse. Snowflake and Redshift support this with Entra ID or Okta. The setup changes where dbt keeps the credentials. Don't type them into the connection. Create a custom integration under Account settings → Integrations and fill in the integration name, client secret, client ID, authorization URL and token URL there. Then create or edit the connection, choose that external OAuth as its OAuth method, and pick the config from the External OAuth configurations box.

Entra ID adds two rules for the client secret. First, you see the secret only once. Microsoft hides it if you leave the page and come back, so a lost secret has to be recreated. Second, every secret expires, after at most two years. Write the expiry date down. When the secret expires, authorization fails for everyone, so you want to replace it before that day. For Okta, the client ID and secret are on the Okta application page.

Sources56

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.A Databricks OAuth client secret can be copied from the app connection later if you forget to save it.Why is that wrong?

   Databricks shows the secret only when it is generated. Copy and store it at that moment.

   Covered in Databricks: generate once, store under Optional settings

2. 2.Adding Databricks OAuth client credentials to the connection also switches deployment jobs to OAuth.Why is that wrong?

   Developer OAuth covers development credentials only. Deployment environments keep their own token-based credentials.

   Covered in Databricks: generate once, store under Optional settings

3. 3.Any Snowflake user with access to the database can create the security integration that produces dbt's client ID and secret.Why is that wrong?

   Creating the integration needs the ACCOUNTADMIN role or the global CREATE INTEGRATION privilege. A dbt admin usually has to work with a Snowflake admin to do it.

   Covered in Snowflake: read the secret from the security integration

4. 4.An Entra ID client secret for external OAuth is set once and never needs attention again.Why is that wrong?

   Entra secrets expire after at most two years. Record the expiry date and replace the secret before user authorization fails.

   Covered in External OAuth: credentials live in an integration, not the connection