Snowflake is a cloud data platform for data warehousing, data lakes, and data sharing. Integrating Snowflake with Frontegg allows your application to execute SQL queries and access data warehouses on behalf of your users using OAuth 2.0.
Prerequisites
Prerequisites
- A Snowflake account with the ACCOUNTADMIN role (required to create security integrations)
Snowflake OAuth integrations are configured using SQL commands in Snowsight. There is no separate developer portal — you create and manage OAuth clients directly within your Snowflake account.
Navigate to app.snowflake.com and sign in to your Snowflake account. The sign-in page asks for your account identifier — the subdomain of your Snowflake URL, either in orgname-accountname form or as an account locator such as xy12345, including any region or cloud segments. Keep it at hand: the same value goes into the Frontegg portal later.
In the left navigation, click Projects — it opens Workspaces, the SQL editor. On the Welcome to Workspaces page, click SQL file to create a new SQL file.
In the SQL file, enter the following command. Replace FRONTEGG_INTEGRATION with your preferred integration name, and replace the OAUTH_REDIRECT_URI value with the redirect URL shown in the Frontegg portal for this integration — copy it whole, including the path. See How to get your Redirect URL.
CREATE OR REPLACE SECURITY INTEGRATION FRONTEGG_INTEGRATION
TYPE = OAUTH
ENABLED = TRUE
OAUTH_CLIENT = CUSTOM
OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
OAUTH_REDIRECT_URI = 'https://YOUR_MCP_GATEWAY_URL/integration-callback'
OAUTH_ISSUE_REFRESH_TOKENS = TRUE
OAUTH_REFRESH_TOKEN_VALIDITY = 7776000;OAUTH_REFRESH_TOKEN_VALIDITY is expressed in seconds, so 7776000 keeps refresh tokens valid for 90 days. Click Run selected to execute the command.
OR REPLACE rotates the client secrets
OR REPLACE rotates the client secrets
CREATE OR REPLACE makes the command safe to re-run, but if an integration with this name already exists, replacing it issues a new pair of client secrets and invalidates the old ones. Any connector already configured with the previous secret stops working until you paste the new one. Use CREATE SECURITY INTEGRATION without OR REPLACE if you want the command to fail rather than replace an existing integration.
After running the command, the results panel shows a confirmation message.
Run the following query to retrieve your OAuth client credentials:
SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('FRONTEGG_INTEGRATION');The result is a JSON object containing:
| Field | Description |
|---|---|
OAUTH_CLIENT_ID | Your Client ID |
OAUTH_CLIENT_SECRET | Your primary Client Secret |
OAUTH_CLIENT_SECRET_2 | A secondary Client Secret (backup) |
Copy your Client Secret now
Copy your Client Secret now
Copy your Client Secret and store it in a secure location. Snowflake does not display it anywhere else in Snowsight — if you lose it, re-run the command from step 3 to issue a new pair.
The values are redacted in the screenshot below; in your own account the row shows the full JSON.
Once you have obtained your credentials, configure the integration in the Frontegg portal:
- Open the Frontegg portal and navigate to [ENVIRONMENT] → Integrations → Snowflake.
- Fill in the four fields described below.
- Click Save.
The subdomain of your Snowflake URL, in orgname-accountname format. For example, if your URL is https://myorg-myaccount.snowflakecomputing.com, your account identifier is myorg-myaccount.
Accounts whose URL uses an account locator (for example https://xy12345.snowflakecomputing.com) work too — use the locator exactly as it appears in the URL, including any region or cloud segments.
Optional. The Snowflake role activated for the OAuth session.
- Default behavior. When this field is empty, the integration runs under the
PUBLICrole — the role auto-granted to every Snowflake user, with minimal privileges. Existing installations that do not set the field continue to behave as before. - When to set it. Provide a role name to operate under a specific role (for example, a custom data-access role like
DATA_ANALYST). - Must already be granted to the OAuth user. The role must be granted to the Snowflake user who completes the OAuth flow. If it is not granted, OAuth fails.
- Case-sensitive. The value must match the output of
SHOW ROLESexactly. - Pick a non-admin role.
ACCOUNTADMIN,SECURITYADMIN,ORGADMIN, andGLOBALORGADMINare in Snowflake's defaultBLOCKED_ROLES_LISTfor OAuth. Setting any of them causes OAuth to silently fail — the user is bounced back to the login screen with no error message. Use a custom role or another non-blocked role instead. - Changing this field after install. Requires re-authorization. The existing refresh token is bound to the previous role's scope. Individual queries cannot switch to a different role either — the role is fixed by the authorization, so a query naming any other role is rejected even when that role is granted to the user. Re-authorizing is the only way to change it.
Paste the OAUTH_CLIENT_ID and OAUTH_CLIENT_SECRET values returned by the SYSTEM$SHOW_OAUTH_CLIENT_SECRETS query you ran earlier.
Once a role is bound to the OAuth session, Snowflake's standard RBAC applies to every query the integration runs:
- Reads of data tables outside the role's grants return
does not exist or not authorized. - Admin metadata schemas (such as
SNOWFLAKE.ACCOUNT_USAGE) are unreachable. SHOW DATABASES,SHOW WAREHOUSES,SHOW USERS, and similar listings are role-filtered — visibility narrows to what the role can see.- Universal metadata views (
INFORMATION_SCHEMA) andPUBLIC-inherited objects remain visible. This is by Snowflake design, not a leak.
Keep your credentials secure
Keep your credentials secure
Never share or commit your Client Secret to version control.
- Values can be passed separately from the SQL. Placeholders in the statement can be filled from a separate set of values rather than pasted into the query text.
- A warehouse is required for data queries. Snowflake runs queries on a warehouse, and the OAuth session inherits the default warehouse of the user who authorized the connection. If that user has no default warehouse, any query touching data fails until a warehouse is named explicitly in the request. Assign a default warehouse to the authorizing user, or pass the warehouse per query.
- Quoted identifiers are not accepted by the object tools. Object names must consist of letters, digits, underscores, and
$, with dots separating the parts of a fully qualified name (MYDB.PUBLIC.CUSTOMERS). Names that require double quotes, such as"My Table", must be queried through the plain SQL execution tool instead. - Long-running statements finish asynchronously. Snowflake returns a still-running response with a statement handle for queries that exceed roughly 45 seconds. The connector then polls that handle for the result, so a slow query returns in a later call rather than in the original one.
- Large result sets arrive in partitions. Snowflake splits big results into partitions and returns only the first one plus partition metadata; the remaining partitions are fetched one at a time.
- Name-prefix and paging filters are available only for some object types. Databases, schemas, tables, views, tasks, streams, roles and users can be filtered by name prefix and paged through. Stages, pipes, functions, procedures, sequences, file formats and warehouses accept only a name pattern — Snowflake ignores the other filters on these types instead of reporting an error, so the connector rejects the request rather than returning a result whose filter was silently discarded. Narrow those listings with a name pattern, or scope them to a database or schema.
- Multi-statement scripts must declare how many statements they contain. Snowflake rejects a semicolon-separated script whose statement count was not stated up front. Send the count along with the script, or submit the statements one at a time.