Configure External OAuth for Snowflake: Client Credentials Flow

OAuth client credentials authentication enables machine-to-machine connections to Snowflake

without user interaction. This method is ideal for:

  • Service accounts for automated data refreshes

  • Scheduled extract jobs

  • CI/CD pipelines

  • Published data sources that require embedded credentials

Unlike standard OAuth (which uses the authorisation code flow), client credentials flow does not

prompt users to sign in. Instead, Tableau authenticates directly with your identity provider using a

client ID and secret.

Note: Client credentials flow requires Snowflake’s External OAuth feature with a supported identity provider. This is different from Snowflake’s native OAuth.

Before you begin

To use OAuth client credentials with Snowflake, you need:

RequirementDescription
Identity providerOkta, Azure AD or Ping Federate configured for client credentials grant
Snowflake accountEnterprise edition or higher with ACCOUNTADMIN access
OAuth applicationAPI Services (Okta), App Registration (Azure AD) or equivalent
Custom scopesScopes for Snowflake role assignment (e.g. ‘session:role:SYSADMIN’)

Configure your identity provider

The following steps use Okta as an example. For other providers, consult their documentation for client credentials configuration.

Step 1: Create an API Services Application

  1. Sign in to your Okta Admin Console.

  2. Go to **Applications > Applications.

  3. Select **Create App Integration.

  4. Choose **API Services** and select **Next.

  5. Enter an application name (for example, snowflake-tableau-service).

  6. Select Save.

  7. Copy the Client ID and Client Secret. You will need these values later.

Step 2: Disable DPoP (if enabled)

Demonstrating Proof of Possession (DPoP) must be disabled for client credentials flow.

  1. In your application settings, go to General > Client Credentials.

  2. Clear the Require Demonstrating Proof of Possession (DPoP) header in token requests tick box.

  3. Select Save.

Step 3: Add Custom Scopes

Snowflake requires custom scopes to assign roles to the authenticated session.

  1. Go to Security > API > Authorisation Servers.

  2. Select the default authorisation server (or your custom server).

  3. Select the Scopes tab, then Add Scope.

  4. Add these scopes:

    Scope NameDescription
    snowflakeGeneral access scope for Snowflake
    session:role:SYSADMINAssigns the SYSADMIN role (adjust for your role)

    Note: Create additional scopes for any other roles your service account needs.

Step 4: Configure an Access Policy

  1. Select the Access Policies tab.

  2. Select an existing policy or create a new one.

  3. Add a rule with these settings:

    • Grant type: Client Credentials

    • Scopes: Any scopes (or select specific scopes)

  4. Select Create Rule or Save.

Configure Snowflake

Run the following SQL statements in Snowflake as ACCOUNTADMIN. Replace the placeholder values with your configuration.

Step 1: Create the External OAuth Integration

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE SECURITY INTEGRATION okta_oauth_integration
  TYPE = EXTERNAL_OAUTH
  ENABLED = TRUE
  EXTERNAL_OAUTH_TYPE = OKTA
  EXTERNAL_OAUTH_ISSUER = 'https://<your-okta-domain>.okta.com/oauth2/default'
  EXTERNAL_OAUTH_JWS_KEYS_URL = 'https://<your-okta-domain>.okta.com/oauth2/
default/v1/keys'
  EXTERNAL_OAUTH_TOKEN_USER_MAPPING_CLAIM = 'sub'
  EXTERNAL_OAUTH_SNOWFLAKE_USER_MAPPING_ATTRIBUTE = 'login_name'
  EXTERNAL_OAUTH_AUDIENCE_LIST = ('api://default', 'snowflake')
EXTERNAL_OAUTH_ANY_ROLE_MODE = 'ENABLE';
ParameterDescription
EXTERNAL_OAUTH_TYPEYour identity provider: OKTA , AZURE or PING_FEDERATE
EXTERNAL_OAUTH_ISSUERThe issuer URL from your authorisation server
EXTERNAL_OAUTH_JWS_KEYS_URLThe JWKS endpoint for token validation
EXTERNAL_OAUTH_TOKEN_USER_MAPPING_CLA IMThe JWT claim that identifies the user. Use sub for Okta.
EXTERNAL_OAUTH_ANY_ROLE_MODESet to ENABLE to allow role assignment via scopes

Step 2: Create a Service User

Create a Snowflake user with a LOGIN_NAME that matches the OAuth client ID.

CREATE USER IF NOT EXISTS service_account_user
LOGIN_NAME = '<your-okta-client-id>'
DISPLAY_NAME = 'OAuth Service Account'
MUST_CHANGE_PASSWORD = FALSE
DISABLED = FALSE;
-- Grant role to the service user
GRANT ROLE SYSADMIN TO USER service_account_user;
-- Set the default role
ALTER USER service_account_user SET DEFAULT_ROLE = 'SYSADMIN';
-- Grant warehouse access
GRANT USAGE ON WAREHOUSE <your-warehouse> TO USER service_account_user;
-- Grant database and schema access
GRANT USAGE ON DATABASE <your-database> TO USER service_account_user;
GRANT USAGE ON SCHEMA <your-database>.<your-schema> TO USER
service_account_user;
GRANT SELECT ON ALL TABLES IN SCHEMA <your-database>.<your-schema> TO USER
service_account_user;

Important: The LOGIN_NAME must exactly match the sub claim in the OAuth token. For Okta API Services applications, this is the Client ID.

Connect from Tableau Desktop

  1. In Tableau Desktop, select Connect > Snowflake.

  2. Enter your connection details:

    FieldValue
    ServerYour Snowflake account URL (e.g. account.snowflakecomputing.com)
    RoleThe role to use (e.g. SYSADMIN)
    WarehouseYour Snowflake warehouse
    AuthenticationOAuth Client Credentials
  3. Enter the OAuth configuration:

    FieldValue
    OAuth Token Request URLhttps://<your-okta-domain>.okta.com/oauth2/default/ v1/token
    UsernameYour OAuth Client ID
    PasswordYour OAuth Client Secret
    OAuth Scopesnowflake session:role:SYSADMIN

    Note: The OAuth Scope must include any custom scopes you configured for role assignment.

  4. Select Sign In.

Publish to Tableau Cloud or Tableau Server

When publishing a workbook or data source that uses OAuth client credentials:

  1. In the Publish dialog, select Edit next to Data Sources.

  2. For Authentication, select Embedded password.

  3. The client credentials are embedded in the published content.

Important: Unlike standard OAuth, client credentials are treated as embedded passwords. Users accessing the published content use the service account credentials, not their own identity.

Credential Rotation

When your OAuth client secret rotates, update the embedded credentials on Tableau Cloud:

  1. Sign in to Tableau Cloud.

  2. Navigate to the published data source.

  3. Select Connections.

  4. Update the connection with the new client secret.

For automated rotation, use the Tableau REST API to update connection credentials programmatically.

Frequently Asked Questions

When should I use OAuth client credentials instead of standard OAuth?

Use client credentials when you need unattended, machine-to-machine authentication. Standard

OAuth requires user interaction for the initial sign-in and periodic reauthentication. Client credentials

use a service account identity and do not require user interaction.

Can I use client credentials with Snowflake’s native OAuth?

No. Snowflake’s native OAuth only supports the authorisation code flow. Client credentials require External OAuth with a supported identity provider (Okta, Azure AD or Ping Federate).

How do I handle secret rotation for published content?

When your OAuth client secret rotates, you must update the embedded credentials in Tableau Cloud. You can do this manually through the Tableau Cloud UI or programmatically using the Tableau REST API. Consider automating this process as part of your secret rotation workflow.

Why does my connection fail with a role error even though EXTERNAL_OAUTH_ANY_ROLE_MODE is enabled?

Snowflake requires role information in the OAuth token. Add a custom scope (e.g. session:role:SYSADMIN) to your authorisation server and include it in the OAuth Scope field when connecting from Tableau.

Troubleshooting

Error messageCauseSolution
‘User does not exist or not authorised’Snowflake user LOGIN_NAME does not match OAuth client IDSet the user’s LOGIN_NAME to match the sub claim (client ID for Okta)
‘The role requested is not listed in the Access Token’Missing role scope in tokenAdd session:role:<ROLE> scope to your authorisation server and include it in OAuth Scope
‘Invalid DPoP proof’DPoP is enabled in OktaDisable ‘Require Demonstrating Proof of Possession (DPoP)’ in your Okta app
‘Invalid scope’Custom scopes not configuredAdd required scopes to your authorisation server; do not include openid
Token validation failureIncorrect JWKS URL or issuerVerify that EXTERNAL_OAUTH_JWS_KEYS _URL and EXTERNAL_OAUTH_ISSUER match your authorisation server

See Also

Thanks for your feedback!Your feedback has been successfully submitted. Thank you!