Auth0 to Snowflake: How to Move Your Data

Moving Auth0 into Snowflake lets you analyse who actually uses your product. Auth0 knows every account and login and nothing about revenue, support load or churn, and the questions worth asking join identity to all three.

This guide covers the managed path with Airbyte. Two things shape the build: the credential that is easiest to obtain is the wrong one for production, and identity data attracts deletion requests that a warehouse does not satisfy as quickly as people assume.

Auth0 to Snowflake at a glance:

Why move data from Auth0 to Snowflake?

Two situations account for most of these pipelines.

The first is understanding your user base commercially. Sign-up cohorts, activation and dormancy are identity questions until you join them to contracts and support tickets, at which point they become business questions. Auth0 holds one side and a warehouse is where the other side lives.

The second is security and access review, since identity data answers who has accounts and which applications exist. If your analysis is heavy transformation over large volumes rather than governed reporting, Auth0 to Databricks suits that shape better than a warehouse will.

What do you need before you start?

Four things, and the first has an easy version that will let you down:

A machine to machine application, authorised against the Management API V2. Created under Applications in the Auth0 dashboard. The Auth0 source documentation covers both routes and is clear that this is the production one.

Read scopes, and only read scopes. Each endpoint documents the scope it needs and they all begin with read. Nothing this pipeline does requires the ability to change anything in your identity provider.

Snowflake objects and a narrow grant. A warehouse, database, schema and a role that can create tables. Give this its own schema, because a table of every user account is not something to leave in a general reporting area.

A view on deletion obligations. Identity data is the dataset most likely to be the subject of an erasure request, so knowing how you will honour one before you have to is considerably easier than afterwards.

If your Snowflake account restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the network policy before you begin.

How do you build an Auth0 to Snowflake pipeline in Airbyte?

Step 1: Create the M2M application rather than copying the token

Auth0 displays a ready-made token in the API Explorer tab of the Management API, and pasting it into Airbyte works immediately, which is exactly why people do it. It suits a connectivity test and not a scheduled pipeline. Create a machine to machine application instead, authorise it against the Management API V2, grant the read scopes your streams need, and use its credentials so the connector can obtain tokens itself.

Step 2: Configure the Auth0 source

Click Sources in the left navigation, then New Source, and select Auth0, following adding a source. Supply your Auth0 domain and the application credentials. If a stream returns nothing, check the scopes on the application before suspecting the connector, since each endpoint requires its own.

Step 3: Configure the Snowflake destination

Click Destinations, then New Destination, and select Snowflake, following adding a destination. Supply the account identifier, warehouse, database, schema and role. User records carry nested metadata objects, and Snowflake holds those natively, so nothing needs flattening on the way in.

Step 4: Create the connection and apply controls immediately

Click Connections, then New connection, select your streams and a sync mode. Daily is ample for identity data, and the connector is bound by Auth0's rate limits so there is nothing to gain from syncing aggressively. Apply masking before anybody is told the schema exists.

Then write down how a deletion request will be executed against these tables, because somebody will eventually ask.

Why is the convenient token the wrong one?

Because it was generated for you to try the API, not to run a pipeline. The token sitting in the API Explorer tab is automatically produced and prominently displayed, and it authenticates perfectly, which makes it an appealing shortcut and a temporary one. A pipeline built on it stops working without anybody having changed anything.

The production arrangement is a machine to machine application authorised against the Management API V2, with the connector obtaining tokens itself from the client credentials. That takes a few more minutes and produces something that keeps running, which is the whole difference between a demonstration and a pipeline.

Grant only scopes beginning with read while you are there. Each Management API endpoint documents the scope it needs, and none of what this connector does requires the ability to modify anything. An integration holding write access to your identity provider is a risk nobody chose deliberately, and read-only removes it at no cost to the pipeline.

What happens when somebody asks to be deleted?

More than running a delete statement, and this is the dataset where it matters most. Identity records are precisely what erasure requests are about, and a copy of every user account in a warehouse is a copy somebody will eventually have to account for. Deleting the row in Auth0 does nothing to your Snowflake table, since nothing propagates that.

The subtler point is that deleting from Snowflake does not immediately make the data unrecoverable either. Time Travel retains prior versions of a table for a period that depends on your edition and configuration, and fail-safe sits beyond that, which is excellent protection against accidents and something to understand when you are asserting that a record is gone.

So decide the procedure before you need it. Know your retention period, agree what you will tell somebody asking about timing, and consider whether masking identifying fields from the outset reduces the problem, since a table nobody can read identities from is a smaller obligation than one they can. Keep the analysis that matters, which is counts and cohorts, and it rarely needs the identities at all.

Frequently asked questions

Can I use the token from the API Explorer?

For testing connectivity, yes. For a scheduled pipeline, no. Create a machine to machine application so the connector can obtain tokens itself.

Which scopes does it need?

Only those beginning with read, and each endpoint documents its own. Nothing here requires write access to your identity provider.

A stream returns nothing. What now?

Check the scopes granted to the application before suspecting anything else, since each endpoint requires its own and a missing one affects only that stream.

Does deleting a user in Auth0 remove them from Snowflake?

No, nothing propagates that. And deleting from Snowflake leaves prior versions in Time Travel for a period, so plan the procedure rather than improvising it.

Can I do this without writing code?

The pipeline, yes. Masking policies and the deletion procedure are SQL and process respectively, and with identity data both are worth having before the first sync.

Get your Auth0 data into Snowflake

Create a machine to machine application rather than pasting the token Auth0 helpfully displays, and grant read scopes only. Give this its own schema with narrow access. Then decide, before the first sync, how an erasure request will be executed, remembering that a delete in Snowflake leaves prior versions in Time Travel for a while. Masking identities from the start makes that obligation smaller and costs almost no analysis.

Airbyte's connector catalog includes 600+ pre-built connectors, so identity data can be analysed beside the commercial reality. For another identity provider into the same destination, see Okta to Snowflake, and for the customer records to join against, Salesforce to Snowflake.

Start syncing now →