What you will be able to do
- Explain what OAuth replaces in a dbt warehouse connection and who configures each part
- Sequence the admin setup for native OAuth with Snowflake, BigQuery and Databricks
- Walk a developer through the one-time authorization in their profile credentials
- Predict when a developer has to reconnect or restart, based on refresh and access token lifetimes
- Distinguish developer OAuth from deployment credentials, and diagnose common OAuth errors
Key concept
Developer OAuth — Each developer signs in through the warehouse's own login or SSO, and dbt holds the token that comes back instead of a stored username and password. Admins set up the integration once, and every developer then authorizes once from their profile.
1.What OAuth replaces in a warehouse connection
OAuth changes which credentials open the warehouse when a developer works in dbt. Without it, each developer types a warehouse username and password into dbt, and dbt stores them. With it, the developer signs in through the warehouse's own login page or its single sign-on, and dbt keeps a token rather than a password. No password is stored in dbt, and every sign-in goes through the rules the warehouse or identity provider already enforces.
The work is split between two groups. Admins configure the OAuth integration once, partly in the warehouse and partly on the dbt connection. After that, each developer completes a one-time authorization from their own profile. The feature is only available on the Enterprise and Enterprise+ plans.
| Platform | OAuth option | Who authenticates the developer |
|---|---|---|
| Snowflake | Snowflake OAuth | Snowflake, or Snowflake SSO |
| Databricks | Databricks OAuth | Databricks |
| BigQuery | BigQuery OAuth | |
| Snowflake (external) | External OAuth with Snowflake | An external identity provider (IdP) |
| Redshift (external) | External OAuth with Redshift | An external identity provider (IdP) |
External OAuth places an identity provider between dbt and the warehouse, so one sign-in covers dbt and the other applications that IdP protects. Only Okta and Entra ID are supported today. An admin creates a custom integration under Account settings → Integrations, then picks it as the OAuth method on the Snowflake connection. One requirement catches teams out: the username the IdP sends has to match the warehouse username exactly. If a developer's email in the IdP differs from their Snowflake username, the connection fails.
Checkpoint 1 of 9· Check yourself
A team wants developers to reach Snowflake through their corporate identity provider using External OAuth. Which requirement must they meet?
External OAuth only supports Okta and Entra ID, and a mismatch between the IdP username and the Snowflake username makes the connection fail.
“This feature is currently only available for Okta and Entra ID identity providers.”Source: docs.getdbt.com
2.The admin setup: redirect URI, integration, connection
Native OAuth setup takes the same three steps on every platform, and their order is fixed because each step needs a value the previous one produced. First, the admin copies the redirect URI from the dbt connection. For Snowflake, that means opening the project's Development connection and setting the OAuth method to Snowflake SSO. Next, a warehouse-side object is created that trusts that URI: a security integration in Snowflake, or an OAuth app in BigQuery or Databricks. That object produces a client ID and secret, which go back into the dbt connection. Where those values are entered for each platform is covered in [entering the OAuth Client ID and Secret](lesson:1.5).
On Snowflake, the trust object is a SQL statement, and both a dbt admin and a Snowflake admin are needed to run the steps. The <REDIRECT_URI> placeholder takes the value copied from dbt. If developers rely on secondary roles, the statement must also include OAUTH_USE_SECONDARY_ROLES = 'IMPLICIT'.
CREATE OR REPLACE SECURITY INTEGRATION DBT_CLOUD
TYPE = OAUTH
ENABLED = TRUE
OAUTH_CLIENT = CUSTOM
OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
OAUTH_REDIRECT_URI = '<REDIRECT_URI>'
OAUTH_ISSUE_REFRESH_TOKENS = TRUE
OAUTH_REFRESH_TOKEN_VALIDITY = 7776000
OAUTH_USE_SECONDARY_ROLES = 'IMPLICIT'; -- Required for secondary rolesRunning this statement needs a lot of privilege: a user with the ACCOUNTADMIN role, or a role holding the global CREATE INTEGRATION privilege. You only need it once per Snowflake account, though. If several dbt projects point at the same Snowflake account, they can all share one security integration.
Checkpoint 2 of 9· Put it in order
Put the admin steps for Snowflake OAuth in order
- 1.Create a security integration in Snowflake
- 2.Locate the redirect URI value in dbt
- 3.Configure a connection in dbt
The security integration needs the redirect URI from dbt, and the dbt connection needs the client ID and secret that the integration produces.
“Locate the redirect URI value in dbt.”Source: docs.getdbt.com
Checkpoint 3 of 9· Exam question
A dbt Cloud admin configures Snowflake OAuth by creating the security integration in Snowflake and entering the Client ID and Secret under Account Settings → Connections. When developers click Connect to Snowflake Account, Snowflake returns an "Invalid consent request" error before the login prompt appears. What is the most likely cause?
Correct answer: A — The role configured in the developer's dbt profile is included in Snowflake's BLOCKED_ROLES_LIST or the developer lacks grants on that role, so Snowflake refuses to issue consent for it.
- A. This is correct. Snowflake evaluates the role a developer supplies against the security integration's blocked-roles configuration and their actual grants at the consent step, so a disallowed or ungranted role produces an invalid-consent response before login even completes.
- B. This is incorrect. The refresh-token setting controls whether a long-lived token is issued after a successful authorization, but it does not gate whether the initial consent screen is displayed, so this setting would not produce a consent error.
- C. This is incorrect. The OAuth handshake authenticates the developer's identity and role against Snowflake; it does not evaluate or require a default warehouse, so a missing warehouse would surface later as a query failure, not a consent error.
- D. This is incorrect. A blocked-cookie scenario typically breaks the redirect back to dbt Cloud after a successful Snowflake login, producing a callback or session error, not Snowflake's own invalid-consent rejection at the authorization step.
Sources3
3.How a developer authorizes their credentials
Once a project's connection uses OAuth, every developer has to authenticate before the Studio IDE will work. They do this from Your profile → Credentials: choose the project, set the authentication method, and click the connect button. The browser goes to the warehouse's sign-in page and then comes back to dbt. If Snowflake already uses SSO through a third-party identity provider, developers sign in through that provider and need no extra setup.
The details differ by platform:
- Snowflake: click Connect to Snowflake Account, authorize with the configured SSO provider, and return to dbt. - Databricks: edit the project credentials, select OAuth, save, then click Connect Databricks Account and approve the connection. - BigQuery: set the Authentication Method to Native OAuth, click Connect to BigQuery, and approve the drive, cloud platform and BigQuery scopes, unless the connection is less privileged.
Snowflake has one rule that the other platforms don't. The role in a developer's profile credentials is required, and it is not taken from the project connection. A role filled in on the project connection page does nothing for a developer who left it blank in their profile. Snowflake role names are also case sensitive, so a role entered in the wrong case fails just as a missing one does.
Checkpoint 4 of 9· Check yourself
An admin set the role ANALYST on a project's Snowflake connection. A developer leaves the role empty in their profile credentials and clicks Connect to Snowflake Account. What happens?
In the Snowflake OAuth flow, every developer must supply their own role. A role on the project connection is not inherited.
“role in the profile config is not optional, as it does not inherit from the project connection config.”Source: docs.getdbt.com
Checkpoint 5 of 9· Exam question
Where does a dbt Cloud admin enter the OAuth Client ID and Client Secret for a Databricks connection that has been configured for OAuth authentication?
Correct answer: A — Under the connection's Optional settings section in Account Settings → Connections, after editing the existing Databricks connection.
- A. This is correct. The Databricks OAuth Client ID and Secret generated in the Databricks account console are pasted into the Optional settings of the Databricks connection under Account Settings → Connections in dbt Cloud.
- B. This is incorrect. The Credentials page is where each developer later selects OAuth as their authentication method and authorizes their own session; the connection-level Client ID and Secret are entered once by an admin, not per developer.
- C. This is incorrect. Registering the custom OAuth application happens in Databricks, but dbt does not read those credentials automatically — an admin must copy the generated Client ID and Secret into dbt Cloud manually.
- D. This is incorrect. Environment variables configure job-level or model-level values evaluated at run time; OAuth connection credentials are stored on the connection object itself, not as environment variables.
4.Refresh tokens, access tokens and re-authentication
Every OAuth session uses two tokens with different jobs. When a developer authorizes, the warehouse sends dbt a refresh token. dbt exchanges that refresh token for an access token, and the access token is what opens the warehouse connection and runs queries for that developer. So there are two separate expiry events, and each one has its own fix.
On Snowflake, OAUTH_REFRESH_TOKEN_VALIDITY in the security integration sets how long the refresh token lasts, in seconds. A smaller value makes developers re-authenticate with Snowflake more often. That is a trade-off between tighter security and more interruptions for developers. When a refresh token expires, the developer has to re-authorize with Snowflake before they can keep developing in dbt.
| Token | Default TTL | Set where | When it expires |
|---|---|---|---|
| Access token | 60 minutes | Databricks OAuth app | Restart the Studio IDE |
| Refresh token | 10080 minutes | Databricks OAuth app | Click Connect Databricks Account again |
Checkpoint 6 of 9· Fill the gap
Which parameter sets how many seconds a developer's Snowflake refresh token stays valid?
OAUTH_ISSUE_REFRESH_TOKENS = TRUE
? = 7776000OAUTH_REFRESH_TOKEN_VALIDITY sets the refresh token lifetime in seconds. When that token expires, the developer must re-authorize with Snowflake.
Source: docs.getdbt.com5.Developer OAuth stops at deployment environments
Developer OAuth covers interactive work by a person, not scheduled jobs. On Databricks it is user-to-machine authentication for the Studio IDE, and it applies only to development credentials. A nightly job can't open a browser and click Connect, so deployment environments use their own credentials, configured at the environment level. For Databricks, the recommended deployment credential for both production and non-production jobs is a token-based profile using a service principal token.
BigQuery has a machine-to-machine OAuth option for deployment: Workload Identity Federation. dbt requests tokens from an Entra ID app, and GCP lets the caller act as a service account, so nobody has to manage service account keys for deployment environments. Because no user is involved in this flow, the Entra app needs no redirect URI. On the BigQuery connection, the admin selects Workload Identity Federation as the Deployment Environment Authentication Method, then picks the custom OAuth integration. Entra ID is currently the only supported IdP for it.
Checkpoint 7 of 9· Check yourself
A project uses Databricks OAuth for development. How should its scheduled production job authenticate?
Developer OAuth only applies to development credentials. Deployment environments use separate token-based credentials, and a service principal token is recommended.
“Deployment environments use separate credentials configured at the environment level. They do not use developer OAuth.”Source: docs.getdbt.com
Checkpoint 8 of 9· Exam question
A dbt Cloud Enterprise team is registering a Databricks custom OAuth application so that Studio IDE developers can run both SQL models and Python models against the warehouse. In the Databricks account console's App connections page, which two access scopes must be granted so both model types run without permission errors?(Select 2)
Correct answers: A, B — The SQL scope, which grants the token permission to execute SQL warehouse queries needed for standard dbt SQL models.; The ALL APIs scope, which grants the broader Databricks REST API access that Python models need to submit compute jobs.
- A. This is correct. The SQL scope is what authorizes the OAuth token to run SQL warehouse queries, which is required for dbt's standard SQL models to execute at all.
- B. This is correct. Python models submit jobs through Databricks' broader REST API surface, so the ALL APIs scope is required in addition to the SQL scope for those models to run.
- C. This is incorrect. Databricks OAuth application setup in dbt Cloud does not list or require a separate Unity Catalog scope; catalog access is governed by the underlying warehouse permissions, not this connection scope.
- D. This is incorrect. A Workspace Admin scope is not one of the access scopes dbt's Databricks OAuth setup requests, and granting broad cluster-policy administration is unrelated to running SQL or Python models.
6.Reading OAuth errors
Most Snowflake OAuth failures show up after the redirect to the Snowflake login page has already worked, so the redirect URI is rarely what's wrong. The exact error message tells you where to look:
- Invalid consent request: the developer cannot use the role in their dbt credentials, the role name is in the wrong case, or the role is on the blocked list. ACCOUNTADMIN is one such role. - The requested scope is invalid: the role is missing from the developer's profile, because profiles don't inherit the role from the project connection. - 500 server error on the way back to dbt: Snowflake isn't allowing dbt's IP addresses, or the VPC Endpoint ID for PrivateLink, at the account level. See [IP allowlisting](lesson:1.2). You may also need to attach the network policy to the security integration.
Checkpoint 9 of 9· Match them up
Match each Snowflake OAuth symptom to its most likely cause
Tap a term, then the definition that fits it.
The first two errors are both about roles: the role exists but can't be used, or it is missing from the profile. The 500 error comes from network allowlisting.
“a role that is in the BLOCKED_ROLES_LIST, such as ACCOUNTADMIN”Source: docs.getdbt.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Once developer OAuth is enabled, scheduled deployment jobs also authenticate with it.Why is that wrong?
Databricks developer OAuth applies only to development credentials. Deployment environments use separate token-based credentials, ideally a service principal token.
2.A Snowflake role set on the project connection is inherited by every developer's OAuth credentials.Why is that wrong?
Each developer must supply their role in their own profile, whatever is set on the project connection.
Covered in How a developer authorizes their credentials
3.An expired Databricks access token is renewed automatically while the Studio IDE stays open.Why is that wrong?
dbt exchanges the refresh token only when a session starts. After the access token expires, the developer has to restart the Studio IDE.
Covered in Refresh tokens, access tokens and re-authentication
4.Each dbt project connecting to the same Snowflake account needs its own security integration.Why is that wrong?
One security integration can serve every dbt project that uses the same Snowflake account.
Covered in The admin setup: redirect URI, integration, connection
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“instead of storing usernames and passwords in dbt platform”
↩︎ What OAuth replaces in a warehouse connection“Admins configure the OAuth integration; developers complete a one-time authorization in their profile.”
↩︎ Key concept - 2.
“If the email address used in the dbt setup is different from the Snowflake email address, the connection will fail”
↩︎ What OAuth replaces in a warehouse connection“for the OAuth method, select the external OAuth you just created.”
↩︎ What OAuth replaces in a warehouse connection“The Snowflake default roles ACCOUNTADMIN, ORGADMIN, or SECURITYADMIN, are blocked from external OAuth by default”
↩︎ Reading OAuth errors“This feature is currently only available for Okta and Entra ID identity providers.”
↩︎ Checkpoint - 3.
“Only Snowflake account administrators (users with the ACCOUNTADMIN role) or a role with the global CREATE INTEGRATION privilege can execute this SQL command.”
↩︎ The admin setup: redirect URI, integration, connection“you can use the same security integration for all of the projects.”
↩︎ The admin setup: redirect URI, integration, connection“To use Snowflake in the Studio IDE, all developers must authenticate with Snowflake in their profile credentials.”
↩︎ How a developer authorizes their credentials“Snowflake will return a Refresh Token to the dbt application”
↩︎ Refresh tokens, access tokens and re-authentication“Use a smaller value to force users to re-authenticate with Snowflake more frequently.”
↩︎ Refresh tokens, access tokens and re-authentication“If you experience a 500 server error when redirected from Snowflake to dbt”
↩︎ Reading OAuth errors“Where possible, use Snowflake External OAuth instead to bypass this limitation.”
↩︎ Reading OAuth errors“each user must supply their role, regardless of whether it is provided in the project connection.”
↩︎ Exam trap 2“you can use the same security integration for all of the projects.”
↩︎ Exam trap 4“Locate the redirect URI value in dbt.”
↩︎ Checkpoint“role in the profile config is not optional, as it does not inherit from the project connection config.”
↩︎ Checkpoint“a role that is in the BLOCKED_ROLES_LIST, such as ACCOUNTADMIN”
↩︎ Checkpoint - 4.
“Select OAuth as the authentication method, and click Save.”
↩︎ How a developer authorizes their credentials“they must click Connect Databricks Account again to re-authenticate.”
↩︎ Refresh tokens, access tokens and re-authentication“A service principal token is recommended for production and non-production jobs.”
↩︎ Developer OAuth stops at deployment environments“It applies to development credentials only.”
↩︎ Exam trap 1“When the access token expires (default: 60 minutes), the user must restart the Studio IDE to continue development.”
↩︎ Exam trap 3“dbt does not fetch new access tokens during an active session.”
↩︎ Prediction“Deployment environments use separate credentials configured at the environment level. They do not use developer OAuth.”
↩︎ Checkpoint - 5.
“asked to approve the drive, cloud platform, and BigQuery scopes, unless the connection is less privileged.”
↩︎ How a developer authorizes their credentials“Workload Identity Federation utilizes a machine-to-machine OAuth flow that is unattended by the user”
↩︎ Developer OAuth stops at deployment environments