> ## Documentation Index
> Fetch the complete documentation index at: https://docs.omni.co/llms.txt
> Use this file to discover all available pages before exploring further.

# OAuth for Snowflake connections

> Authenticate individual users against your Snowflake database with OAuth, enforcing database-level permissions in Omni.

<Note>
  Reach out to Omni support to have database OAuth enabled.
</Note>

By default, Omni queries your Snowflake database using a shared service account. With OAuth, each user authenticates with their own credentials, and Omni enforces that user's Snowflake database-level permissions when they run queries. This lets you manage data access in Snowflake and have it filter down to Omni automatically.

## OAuth types

Omni supports two OAuth modes for Snowflake. Both enforce per-user database permissions, but they differ in how users authenticate.

<Warning>
  Before configuring OAuth, review the [limitations](/connect-data/oauth#limitations) that apply to both types.
</Warning>

### Native OAuth

With native OAuth, users authenticate directly with Snowflake's built-in OAuth server. When a user runs a query for the first time, they're prompted to sign in with their Snowflake credentials.

This is the simpler option — it doesn't require an external identity provider and can be configured entirely between Omni and Snowflake.

<Card title="Snowflake native OAuth" icon="snowflake" color="#FF5FA2" href="/connect-data/oauth/snowflake/native">
  Set up native OAuth for Snowflake
</Card>

### External OAuth

With External OAuth, users authenticate through an external identity provider (IdP) such as Okta, Entra ID (Azure AD), or Ping Identity. The IdP issues a token that Snowflake trusts, so users sign in with their existing corporate identity rather than separate database credentials.

This option is more complex to configure — it involves setup in the IdP, Snowflake, and Omni — but it centralizes authentication through the identity provider your organization already uses.

<Card title="Snowflake + Okta External OAuth" icon="snowflake" color="#FF5FA2" href="/connect-data/oauth/snowflake/external-okta">
  Set up federated OAuth for Snowflake connections using Okta
</Card>

<Card title="Snowflake + Microsoft Entra ID External OAuth" icon="snowflake" color="#FF5FA2" href="/connect-data/oauth/snowflake/external-entra">
  Set up federated OAuth for Snowflake connections using Microsoft Entra ID (Azure AD)
</Card>

**Looking for another IdP?** A guide for Ping Identity is coming soon.

## Warehouse configuration

Omni's Snowflake OAuth integration supports per-user warehouse routing through a user's assign `DEFAULT_WAREHOUSE`. This is useful for organizations that manage role-to-warehouse mappings in Snowflake for per-user or per-team cost attribution. Instead of pinning all users to a single warehouse in Omni, each user's queries route to their assigned warehouse based on their Snowflake configuration.

Before implementing, note that:

* **Your users must have an assigned `DEFAULT_WAREHOUSE` in Snowflake to use this feature.** Otherwise they'll receive `No active warehouse` errors when they try to run queries in Omni.
* **Model-level [`compute_routing`](/modeling/models/compute-routing) and [`warehouse_override`](/modeling/models/warehouse-override) settings take precedence over user default warehouses.**

See the OAuth setup guides for more information.

## Limitations

Before enabling OAuth for Snowflake, review the [Limitations for OAuth](/connect-data/oauth#limitations). **These limitations apply to both Native and External OAuth**.

## Related

* [Troubleshooting Snowflake OAuth](/connect-data/oauth/snowflake/troubleshooting) - Diagnose and resolve common issues with Omni's Snowflake OAuth integration
* [Access grants](/modeling/models/access-grants) — Control which fields and tables are visible to each user in the model and field browser
* [Content permissions](/administration/users/permissions) — Control which dashboards and documents users can access