This feature is currently only available for the Okta and Entra ID identity providers and Snowflake connections.
dbt Cloud Enterprise supports external OAuth authentication with external providers. When External OAuth is enabled, users can authorize their Development credentials using single sign-on (SSO) via the identity provider (IdP). This grants users authorization to access multiple applications, including dbt Cloud, without their credentials being shared with the service. Not only does this make the process of authenticating for development environments easier on the user, it provides an additional layer of security to your dbt Cloud account.
The process of setting up external OAuth will require a little bit of back-and-forth between your dbt Cloud, IdP, and Snowflake accounts, and having them open in multiple browser tabs will help speed up the configuration process:
dbt Cloud: You’ll primarily be working in the Account Settings —> Integrations page. You will need proper permission to set up the integration and create the connections.
Okta: You’ll be working in multiple areas of the Okta account, but you can start in the Applications section. You will need permissions to create an application and an authorization server.
Entra ID An admin with access to create Entra ID apps who is also a user in Snowflake is required.
If the admins that handle these products are all different people, it’s better to have them coordinating simultaneously to reduce friction.
The external_oauth_token_user_mapping_claim and external_oauth_snowflake_user_mapping_attribute can be modified based on the your organizations needs. These values point to the claim in the users’ token. In the example, Snowflake will look up the Snowflake user whose email matches the value in the sub claim.
Note: The Snowflake default roles ACCOUNTADMIN, ORGADMIN, or SECURITYADMIN, are blocked from external OAuth by default and they will likely fail to authenticate. See the Snowflake documentation for more information.
Select a supported identity provider (IdP) for instructions on configuring external OAuth in their environment and completing the integration in dbt Cloud.
In your dbt Cloud account, navigate to Account settings —> Integrations.
Scroll down to Custom integrations and click Add integrations
Leave this window open. You can set the Integration type to Okta and note the Redirect URI at the bottom of the page. Copy this to your clipboard for use in the next steps.
Copy the callback URI at the bottom of the integration page in dbt Cloud
Expand the Security section and click API from the Okta sidebar menu.
On the API screen, click Add authorization server. Give the authorization server a name (a nickname for your Snowflake account would be appropriate). For the Audience field, copy and paste your Snowflake login URL (for example, https://abdc-ef1234.snowflakecomputing.com). Give the server an appropriate description and click Save.
The Okta API window with the Audience value set to the Snowflake URL
On the authorization server config screen, open the Metadata URI in a new tab. You’ll need information from this screen in later steps.
The Okta API settings page with the metadata URI highlighted
Sample output of the metadata URI
Click on the Scopes tab and Add scope. In the Name field, add session:role-any. (Optional) Configure Display phrase and Description and click Create.
API scope configured in the Add Scope window
Open the Access policies tab and click Add policy. Give the policy a Name and Description and set Assign to as The following clients. Start typing the name of the app you created in step 2.3, and you’ll see it autofill. Select the app and click Create Policy.
Assignment field autofilling the value
On the access policy screen, click Add rule.
API Add rule button highlighted
Give the rule a descriptive name and scroll down to token lifetimes. Configure the Access token lifetime is, Refresh token lifetime is, and but will expire if not used every settings according to your organizational policies. We recommend the defaults of 1 hour and 90 days. Stricter rules increase the odds of your users having to re-authenticate.
Toke lifetime settings in the API rule window
Navigate back to the Settings tab and leave it open in your browser. You’ll need some of the information in later steps.
Change your_integration_name to something appropriately descriptive. For example, dev_OktaAccountNumber_okta. Copy the external_oauth_issuer and external_oauth_jws_keys_url from the metadata URI in step 3.3. Use the same Snowflake URL you entered in step 3.2 as the external_oauth_audience_list.
Adjust the other settings as needed to meet your organization's configurations in Okta and Snowflake.
The issuer and jws keys URIs in the metadata URL
Run the steps to create the integration in Snowflake.
Navigate back to the dbt Cloud Account settings —> Integrations page you were on at the beginning. It’s time to start filling out all of the fields.
Integration name: Give the integration a descriptive name that includes identifying information about the Okta environment so future users won’t have to guess where it belongs.
Client ID and Client secrets: Retrieve these from the Okta application page.
TThe client ID and secret highlighted in the Okta app
Authorize URL and Token URL: Found in the metadata URI.
The authorize and token URLs highlighted in the metadata URI
In your dbt Cloud account, navigate to Account settings —> Integrations.
Scroll down to Custom integrations and click Add integrations.
Leave this window open. You can set the Integration type to Entra ID and note the Redirect URI at the bottom of the page. Copy this to your clipboard for use in the next steps.
From the app registrations screen, click New registration.
Give the app a name.
Ensure Supported account types are set to “Accounts in this organizational directory only (Org name - Single Tenant).”
Click Registerto see the application’s overview.
From the app overview page, click Expose an API from the left menu.
Click Add next to Application ID URI. The field will automatically populate. Click Save.
Record the value field for use in a future step. This is only displayed once. Be sure to record it immediately. Microsoft hides the field when you leave the page and come back.
From the same screen, click Add scope.
Give the scope a name.
Set “Who can consent?” to Admins and users.
Set Admin consent display name session:role-any and give it a description.
From the App registration page, click New registration.
Give the app a name that uniquely identifies it as the client app.
Ensure Supported account types are set to “Accounts in this organizational directory only (Org name - Single Tenant).”
Set the Redirect URI to Web and copy/paste the Redirect URI from dbt Cloud into the field.
Click Register.
From the app overview page, click API permissions from the left menu, and click Add permission.
From the pop-out screen, click APIs my organization uses, search for the resource server name from the previous steps, and click it.
Ensure the box for the Permissionssession:role-any is enabled and click Add permissions.
Click Grant admin consent and from the popup modal click Yes.
From the left menu, click Certificates and secrets and click New client secret. Name the secret, set an expiration, and click Add.
Note: Microsoft does not allow “forever” as an expiration date. The maximum time is two years. Documenting the expiration date so you can refresh the secret before the expiration or user authorization fails is essential.
Record the value for use in a future step and record it immediately.
Note: Entra ID will not display this value again once you navigate away from this screen.
Navigate back to the dbt Cloud Account settings —> Integrations page you were on at the beginning. It’s time to start filling out all of the fields. There will be some back-and-forth between the Entra ID account and dbt Cloud.
Integration name: Give the integration a descriptive name that includes identifying information about the Entra ID environment so future users won’t have to guess where it belongs.
Client secrets: Found in the Client ID from the Certificates and secrets page. Value is the Client secret. Note that it only appears when created; Microsoft hides the secret if you return later, and you must recreate it.
Client ID: Copy the’ Application (client) ID’ on the overview page for the client ID app.
Authorization URL and Token URL: From the client ID app, open the Endpoints tab. These URLs map to the OAuth 2.0 authorization endpoint (v2) and OAuth 2.0 token endpoint (v2) fields. You must use v2 of the OAuth 2.0 authorization endpoint. Do not use V1. You can use either version of the OAuth 2.0 token endpoint.
Application ID URI: Copy the Application ID URI field from the resource server’s Overview screen.
Receiving a `Failed to connect to DB` error when connecting to Snowflake
If you see this error:
Failed to connect to DB: xxxxxxx.snowflakecomputing.com:443. The role requested in the connection, or the default role if none was requested in the connection ('xxxxx'), is not listed in the Access Token or was filtered. Please specify another role, or contact your OAuth Authorization server administrator.
Edit your OAuth Security integration and explicitly specify this scope mapping attribute:
ALTER INTEGRATION <my_int_name>SET EXTERNAL_OAUTH_SCOPE_MAPPING_ATTRIBUTE ='scp';
Failed to connect to DB: xxxxxxx.snowflakecomputing.com:443. Incorrect username or password was specified.
Double check that:
There is not more than a single Snowflake user that shares the same email identifier. For example - there exist a human user that authenticates to Snowflake with the email alice@acme.com but at the same time there also exist a separate service account user that also authenticates with alice@acme.com.
The email address of your user in Snowflake is identical to the email address you use to authenticate in your IdP. For example - if your Snowflake users email address is alice@acme.com but you authenticate in Entra/Okta with alice_adm@acme.com - then those email addresses are not the same and you may see this error.