> ## 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 database connections

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

<Note>
  Reach out to Omni support to have this feature enabled in your Omni instance.
</Note>

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

## How it works

When OAuth is enabled on a connection, Omni prompts each user to authenticate with the database the first time they run a query. After authenticating, the user's own database permissions apply to every query they run — rather than the permissions of the shared service account.

A service account is still required on the connection. Omni uses it to build the model, which provides the foundation for all user queries.

## Getting started

Select your database to get started:

<Card title="Snowflake" icon="snowflake" href="/connect-data/oauth/snowflake">
  Configure OAuth for Snowflake connections, including native and External OAuth options.
</Card>

## Limitations

Before enabling OAuth, review the following limitations.

| Area                   | Details                                                                                                                                                                                                   |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Model and IDE**      | Omni models are built using the service account. All users will see the same tables and fields in the model unless you restrict visibility with [access grants](/modeling/models/access-grants).          |
| **Field picker**       | All fields and tables will be visible in the workbook's field browser unless explicitly restricted with access grants.                                                                                    |
| **Scheduling**         | Schedules run as the schedule creator and cannot be personalized with user attributes. Schedules may also fail when the creator's OAuth token expires — the creator must re-authenticate to resolve this. |
| **Caching**            | Caches are not shared across users, which results in a lower cache hit rate and higher data warehouse costs. The same applies to cubes and extracts.                                                      |
| **Content visibility** | Users may be able to open dashboards that reference data they don't have database permissions to query, which can result in permission errors.                                                            |

<Note>
  Some databases may have additional limitations. Check the setup guide for your database for details.
</Note>

## Related

* [**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