Snowflake Connector

This guide covers implementing Descope's Snowflake connector. Snowflake is a cloud-based data warehouse platform for storage, processing, and analytics.

Descope enables you to automatically collect authentication logs and audit events and stream them to your Snowflake data warehouse for centralized analysis and long-term storage.

Configure Snowflake connector

Prerequisites

Before configuring the Descope Snowflake connector, ensure you have:

1. A Snowflake account with appropriate permissions
2. A warehouse, database, and schema created in Snowflake
3. A user account with write permissions for the target database and table. Unless you enable Self Provision, the user also needs CREATE DATABASE, CREATE SCHEMA, and CREATE TABLE privileges.
4. Credentials for one of the two authentication methods: a Programmatic Access Token or an RSA key pair

Configuring the Connector

Navigate to the Connectors page in the Descope Console and select Snowflake to create a new Snowflake connector.

The following parameters are required to use it:

• Connector Name: Provide a unique name for your connector. This assists in distinguishing it, especially when multiple connectors are derived from the same template.
• Connector Description (optional): Briefly explain the purpose of this connector.
• Authentication Method: Choose Programmatic Access Token or Key Pair. Only the fields for the selected method are used. See Authentication Methods.
• Programmatic Access Token: A Snowflake PAT used to authenticate API requests. Shown when Programmatic Access Token is selected.
• Snowflake Username: The Snowflake user the public key is registered on. Shown when Key Pair is selected.
• Private Key: The RSA private key (2048-bit or stronger) in PEM format. Accepted file formats are .pem, .crt, .cer, .key, and .txt. Shown when Key Pair is selected.
• Private Key Passphrase (optional): The passphrase for the private key. Required only if the key is passphrase-protected; leave empty otherwise. Shown when Key Pair is selected.
• Account Identifier (optional): Overrides the account identifier that Descope derives from the Account URL. Only needed for PrivateLink or legacy region locators. Shown when Key Pair is selected.
• Account URL: The URL of your Snowflake account. e.g. https://<org>-<account>.snowflakecomputing.com. Found in Snowsight under Admin > Accounts. Required for both authentication methods.
• Warehouse: The Snowflake warehouse to use for query execution. Defaults to COMPUTE_WH. Case-sensitive.
• Database: The Snowflake database where audit events will be stored. Defaults to DESCOPE_EXPORT_DB. Case-sensitive.
• Schema: The schema within the database for organizing audit event tables. Defaults to PUBLIC. Case-sensitive.
• Audit Table: The table to write audit events to. Defaults to DESCOPE_AUDIT_LOGS. Case-sensitive.
• Self Provision: Off by default, meaning Descope creates the database, schema, and table for you. Turn it on to create them yourself. See Self Provision.
• Stream Audit Events: Select this if you want to stream audit events to your Snowflake account.
• Minimum Write Interval (minutes): The minimum time between writes to Snowflake. When set, Descope accumulates events and writes them in a single batch at most once per interval. See Choosing a Write Interval below, for more details.
• Stream Troubleshooting Events: Decide whether troubleshooting events are also sent to Snowflake.
• Mask PII Data: Decide whether to mask PII (personally identifiable information) in the logs.

Authentication Methods

Pick one of two methods with Authentication Method.

Programmatic Access Token

A Snowflake PAT authenticates each request directly. Snowflake requires a Network Policy attached to the user before a token can be generated or used, and that policy must allow Descope's Project Static IPs for your region, because audit connectors send requests from those addresses. Snowflake also limits the token's lifetime, so you must rotate the token on that schedule.

Key Pair

Key-pair authentication signs every request with a short-lived JWT instead of sending a long-lived secret. There is no network-policy prerequisite and no Snowflake-imposed expiry, so there is no token to rotate.

1. Generate a 2048-bit RSA key pair. Snowflake recommends protecting the private key with a passphrase:

   openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 aes-256-cbc -inform PEM -out rsa_key.pem
   openssl rsa -in rsa_key.pem -pubout -out rsa_key.pub

   The first command prompts for a passphrase. To generate an unencrypted key instead, add -nocrypt and leave Private Key Passphrase empty.

2. Register the public key (rsa_key.pub) on the Snowflake user, following Snowflake's key-pair authentication documentation:

   ALTER USER <user> SET RSA_PUBLIC_KEY='MIIBIjANBgkqh...';

3. In the connector, set Snowflake Username to <user>, upload rsa_key.pem as the Private Key, and enter the passphrase in Private Key Passphrase if you set one.

Descope stores the private key and passphrase KMS-encrypted and never returns them.

To rotate the key without downtime, use Snowflake's second key slot. Upload the new private key in the connector and run Test before you remove the old public key from Snowflake:

-- Check which slot is in use: DESC USER <user>; (RSA_PUBLIC_KEY_FP / RSA_PUBLIC_KEY_2_FP)
-- Set the new key in the empty slot (shown here: slot 2)
ALTER USER <user> SET RSA_PUBLIC_KEY_2='<new public key>';
-- upload the new private key in the connector, then test
-- Remove the old key from the other slot
ALTER USER <user> UNSET RSA_PUBLIC_KEY;

Self Provision

By default, Descope creates the database, schema, and table on first use, so the Snowflake user needs CREATE DATABASE, CREATE SCHEMA, and CREATE TABLE privileges.

To avoid granting those privileges, enable Self Provision. The connector then issues no CREATE statements and writes directly to the warehouse, database, and schema you specify, so it only needs USAGE on the warehouse, database, and schema and INSERT on the audit table. You must create the objects yourself first. See Configuring the Database, Schema, and Table.

Choosing a Write Interval

Snowflake bills compute per second with a one-minute minimum per resume, and a running warehouse burns credits even when idle. Frequent small inserts keep it awake.

Batching into one write per interval lets it auto-suspend between writes. Set the auto-suspend timeout shorter than the interval, or it never suspends.

The tradeoff is latency: a 15-minute interval means events land up to 15 minutes late. Descope queues them rather than dropping them.

Use an interval of 0 minutes for alerting. Use a longer interval for dashboards and storage.

Testing

Before creating your connector, verify that the connector's configuration works. Once configured, simply click on "Test" and check the Test Results panel. Confirm, then click "Create."

Configuring the Database, Schema, and Table

Audit events are stored in a single table with two columns:

Default fully qualified name: DESCOPE_EXPORT_DB.PUBLIC.DESCOPE_AUDIT_LOGS.

If you create the objects yourself in Snowflake, example DDL:

CREATE DATABASE IF NOT EXISTS DESCOPE_EXPORT_DB;

CREATE SCHEMA IF NOT EXISTS DESCOPE_EXPORT_DB.PUBLIC;

CREATE TABLE IF NOT EXISTS DESCOPE_EXPORT_DB.PUBLIC.DESCOPE_AUDIT_LOGS (
    DATA VARIANT,
    CREATED_AT TIMESTAMP_LTZ DEFAULT CURRENT_TIMESTAMP()
);

Snowflake stores unquoted identifiers in uppercase, and the connector sends Warehouse, Database, Schema, and Audit Table to Snowflake case-sensitively. For example, CREATE WAREHOUSE descope_wh creates DESCOPE_WH, so entering descope_wh in the connector will not resolve. To check the stored names, run SHOW WAREHOUSES;, SHOW DATABASES;, SHOW SCHEMAS IN DATABASE DESCOPE_EXPORT_DB;, and SHOW TABLES IN SCHEMA DESCOPE_EXPORT_DB.PUBLIC;.

Grant the connector user (via its role) permission to insert into the table and use the warehouse, for example:

-- Replace MY_ROLE and COMPUTE_WH with your role and warehouse names
GRANT USAGE ON DATABASE DESCOPE_EXPORT_DB TO ROLE MY_ROLE;
GRANT USAGE ON SCHEMA DESCOPE_EXPORT_DB.PUBLIC TO ROLE MY_ROLE;
GRANT INSERT ON TABLE DESCOPE_EXPORT_DB.PUBLIC.DESCOPE_AUDIT_LOGS TO ROLE MY_ROLE;
GRANT USAGE ON WAREHOUSE COMPUTE_WH TO ROLE MY_ROLE;

Adjust grants if your Snowflake admin uses different roles or if the connector uses a warehouse other than COMPUTE_WH.

Troubleshooting

If Test fails, check the error in the Test Results panel. Common causes:

• Warehouse not found: No active warehouse selected in the current session. The warehouse name did not resolve, so the session was left without a warehouse. This error does not mean the field was empty. Check the name's case against SHOW WAREHOUSES;.
• Database, Schema, or Audit Table not found: an object does not exist or not authorized. Check the name's case, and confirm the user's role has USAGE on the database and schema and INSERT on the table.
• Missing privileges to create objects: With Self Provision off, the user needs CREATE DATABASE, CREATE SCHEMA, and CREATE TABLE. Either grant them, or create the objects yourself and enable Self Provision.
• Key Pair authentication fails: Confirm the public key is registered on the Snowflake user (DESC USER <user>; shows RSA_PUBLIC_KEY_FP), that Snowflake Username matches that user, and that the private key matches the registered public key. If the private key is encrypted, enter its passphrase in Private Key Passphrase.
• Account Identifier issues: Descope derives the identifier from Account URL. Set Account Identifier only if you use PrivateLink or a legacy region locator.
• Connector test fails with a 401 error: The credentials themselves are rejected, whether a Programmatic Access Token or a Key Pair. Verify the token or key is current and has not been rotated or revoked on the Snowflake side.
• Connector test fails with a 422 error, but authentication succeeds: Check whether the database, schema, and table configured above actually exist in Snowflake. If Self Provision is checked, Descope assumes those objects already exist and will not create them; if they are missing, the request fails resolving the table path before it ever reaches Snowflake's query engine, which is why Login History shows a successful authentication while Query History stays empty. Either uncheck Self Provision so Descope creates the objects automatically, or create them yourself first using the exact names configured above.
• Diagnosing where a failure is coming from: In Snowflake, check Account > Login History to confirm whether authentication itself succeeded, and Query History to confirm whether any query was ever attempted. Authentication succeeding with no query ever appearing points to a problem resolving the configured database/schema/table, not a credentials problem.

Viewing Audit Logs

Now the audit logs are viewable in Snowflake.

Query recent rows (default table name DESCOPE_AUDIT_LOGS):

SELECT DATA, CREATED_AT
FROM DESCOPE_EXPORT_DB.PUBLIC.DESCOPE_AUDIT_LOGS
ORDER BY CREATED_AT DESC
LIMIT 100;

Exact keys inside DATA depend on the event type; inspect sample rows or your audit event schema in Descope.

The logs can still be viewed in Descope under the Audit and Troubleshoot section of the Descope Console. For more information on audit trail streaming, see Audit Trail Streaming.