You can use OAuth with your Snowflake connections for centralized permission management between your Snowflake warehouse and your Sigma organization. Managing data access from a single location facilitates stronger data access security and decreases Admin time investment for faster permission rollouts.
- Admin privileges in your Sigma organization; see User account types.
- ACCOUNTADMIN role on your Snowflake warehouse (ensure that your default ROLE is not set to ACCOUNTADMIN, ORGADMIN, or SECURITYADMIN in Snowflake).
- Okta, Azure AD, or Ping as your Identity Provider (IdP).
- A Sigma connection to your Snowflake warehouse.
OAuth is a single sign-on (SSO) authorization framework that allows your users to securely log in to applications without the need for a username and password. This authorization happens between a client (you and your users) and one or more resources (i.e. Sigma and Snowflake) via your IdP.
Your IdP uses an authentication server and short-lived tokens to authenticate your application’s users.
Configuring OAuth with Snowflake and Sigma will allow you to pass Snowflake roles to Sigma organization members. This is accomplished by establishing a chain of trust between your IdP, Snowflake warehouse, and Sigma.
After you configure these three entities, you can enable OAuth on a per-connection basis in Sigma for any of your Snowflake connections.
OAuth tokens may expire if the author goes a significant amount of time without logging into Sigma. Such an occurrence will affect schedules. This limitation can be avoided by running the dashboard as a service account.
Snowflake with OAuth requires configuration between an IdP, Snowflake and Sigma. This feature uses Snowflake’s External OAuth capabilities.
- Create an App for Sigma in your IdPO
- Add OAuth Users to your App
- Create an OAuth Authorization Server
- Add an Access Policy for the Authorization Server
- Create a Security Integration in Snowflake
- Configure Sigma to trust the IdP
- Configure your Connection
The exact implementation of steps 1-3 varies depending on your IdP. Please visit their documentation for detailed instructions. If you are using Azure, follow our Azure specific instructions.
You will first need to create a Web OpenID Connect app within your IdP for Sigma. Within the app, please:
- Enable the authorization code grant type.
- Enable the refresh token grant type.
- Set your login redirect URL. Typically, this will be
However, if you are running Sigma on AWS, please use
Creating your Sigma OAuth app will generate a Client ID and Client Secret. Both fields will be used for configuration in Sigma (Step 6).
After creating your OAuth app, you will need to add a list of your OAuth users. These users will be mapped to both Sigma and Snowflake. Access to Snowflake roles is defined on the authorization server (Step 3).
All users must also have permission to access the warehouse in Snowflake.
An authorization server is used to connect your users to Snowflake roles. Please create an authorization server in your IdP.
Authorization Server configuration requires the following values:
session:role-any - requests that the Snowflake access tokens received by Sigma have permission to assume any Snowflake role the user has been granted
offline_access - requests a refresh token that can be used to get new access tokens "offline" (without asking a human user to re-authenticate with the IdP)
openid - requests an OpenID token that can be used to authenticate the user to Sigma
email - requests that the OpenID token include the user's email
profile - requests that the OpenID token include other information from the user's profile (including the user's full name)
snowflake_username = <username>
Claims allow you to connect your OAuth users to user roles in your Snowflake warehouse. Claim definitions are IdP dependent.
The authorization server provides a metadata URI. This id is needed for OAuth configuration within Sigma (step 6). The server also provides an issuer url and jws keys url, both of which are needed for the Snowflake security integration (step 5).
OKTA requires OKTA API Access Management to be enabled in your OKTA instance to create an authorization server.
- Create and/or assign an access policy to your new app (created in step 1). Access policies define rules for access and token lifetimes on an individual app.
- Within the access policy, define access and refresh token lifetimes as desired for all grant types, users, and scopes.
Creating a security integration allows Snowflake to trust your IdP; see Snowflake documentation on Create Security Integration.
The following is an (Okta) example of the command you will need to run in Snowflake. Command values vary slightly depending on your IdP.
create security integration
type = external_oauth
enabled = true
external_oauth_type = okta
external_oauth_issuer = 'https://.okta.com/oauth2/'
external_oauth_jws_keys_url = 'https://.okta.com/oauth2//v1/keys'
external_oauth_token_user_mapping_claim = 'snowflake_username'
external_oauth_snowflake_user_mapping_attribute = 'login_name'
external_oauth_any_role_mode = 'ENABLE';
- Open your Admin Portal by selecting Administration in the user menu at the top right of your screen.
- Select the Authentication page from the left hand panel.
- Click the blue Edit button under Authentication Method and Options.
- Select ‘OAuth’ or ‘OAuth or Password’ from the Authentication Method dropdown menu.
- Under Metadata URI, enter the OAuth metadata URI from your authorization server.
- Under Client ID, enter the client ID from your OAuth application.
- Under Client Secret, enter the client secret from your OAuth application.
- Click Save.
- Test your OAuth configuration by logging out and logging back into Sigma. Your organization’s login page should now display a ‘Log in with SSO’ button.
After you have configured permission inheritance with your IdP and Snowflake, you will need to enable OAuth your Snowflake connection(s). This is done on a per-connection basis. See Connect to Snowflake.
OAuth-enabled connections may be run with or without a service account.
If you select the service account option on your connection, you will be prompted to provide a Snowflake user and password.
Optionally, you can choose the Run as service account setting on individual dashboards/workbooks. This setting queries the published version of the dashboard using the service account’s credentials whenever it is viewed from within Sigma or run as part of a scheduled report. This ensures that any user with Sigma permissions on a dashboard/workbook will be able to view it regardless of warehouse permissions.
All other queries are run against your warehouse using the requesting organization member's Snowflake OAuth credentials.
To select this option, create a connection with both “OAuth Access” and “Service Account” switched on.
A service account is a Snowflake user account implemented for admin purposes in Sigma. It is the same as any other Snowflake user account. However, it should be granted the default role permission you would like on your connection, as well as permission to access the warehouse.
Your service account must be added to the OAuth user list, like all other OAuth accounts on the connection.
This action requires Admin privileges.
- Open the Workbook.
- If the Workbook is in edit mode, click the green ‘Publish’ button in the top right corner of the page.
- Click on the Share option inside the Workbook's menu
- This will open the Share modal. Navigate to the modal's Who has Access tab.
- Switch on Run as service account.
- Click Save.
When this option is selected, you will not be prompted to provide a username or password for the connection. Sigma will always run queries with the organization member's Snowflake OAuth credentials. This includes when users are viewing Datasets and Workbooks owned by others.
This overrides the typical non-OAuth behavior where the Dataset or Workbook owner's permission to the source data is evaluated within Sigma and then the queries are run using the Snowflake user account credentials set in the Connection's settings.
To select this option, create a connection with “OAuth Access” switched on and “Service Account” switched off.
By default, Snowflake connections do not use OAuth. This option remains available even if your organization has OAuth configured.
When a Sigma organization member accesses data from a non-OAuth connection, their permission to the source data is evaluated within Sigma and then the queries are run using the Snowflake user account credentials set in the Connection's settings.
To select this option, create a connection with “OAuth Access” switched off.
Updated 29 days ago