Authenticating into Snowflake: A Practical Guide for Users and Services
In this guide, we break down the different ways to authenticate into Snowflake — whether you’re a data analyst using the UI, a data engineer developing locally, deploying a dbt process running in CI, or deploying a service calling Snowflake programmatically. We’ll also walk through when to use each method and how to implement them securely.
Why Authentication Matters in Snowflake
Snowflake supports many authentication mechanisms because it serves many use cases:
- Interactive human users (UI, SQL clients, BI tools)
- Scheduled workflows (ELT pipelines, dbt runs, BI refresh etc.)
- External apps or services accessing Snowflake programmatically
Choosing the right method impacts:
- Security posture (e.g., credential management, key rotation)
- Developer experience (e.g. MFA bypass)
- Integration patterns (e.g., SSO vs PATs)
1a. Username & Password with MFA
This is the most basic method for human users.
Use for: Admins, analysts, developers logging into the UI or SQL editors.
Enhance with:
- Default push based MFA notification — quicker than one time token
- Network policies to restrict by IP (recommended)
Limitations:
- Not ideal for services or automation
- Can’t rotate passwords easily without user intervention
1b. Username & Password with Passkey (Snowflake’s Preferred MFA Alternative for Human Users)
Snowflake supports passkeys as a secure, phishing-resistant alternative to traditional MFA codes for human users.
With this method, you still enter your username and password, but instead of using an authenticator app, you verify your identity with a passkey stored on your device (e.g., Face ID, Touch ID, Google Password Manager stored security key, etc.).
Use for:
Human users who log in with username/password and want to replace MFA devices/apps.
Benefits:
- Removes the need for a separate MFA device or app
- Resistant to phishing and man-in-the-middle attacks
- Faster logins for frequent users on trusted devices
Limitations:
- Still requires remembering and entering your password — not a passwordless alternative
- Not supported for service accounts or programmatic connections
- Passkey is tied to your device (or synced via OS account) — loss requires re-enrollment
Setup involves:
- Log into Snowsight with username/password.
- Go to Settings → Authentication → Add new Authentication Method
- Click Passkey and follow your browser/device prompts.
On future logins, enter your password and authenticate via passkey — no MFA code required
2. SSO with Identity Provider (e.g., Azure AD, Okta)
For human users logging directly into Snowflake’s UI (Snowsight) or via a SQL editor, Snowflake supports Single Sign-On (SSO) with enterprise identity providers like Azure AD, Okta, Ping, and other SAML 2.0-compliant vendors.
Use for: Analysts, admins, and developers who access Snowflake interactively.
Benefits:
- Centralized user lifecycle management in the IdP
- MFA and conditional access policies applied automatically
- SCIM support for provisioning/deprovisioning
Limitations:
- Only works for human users — cannot be used for most service accounts or scheduled data refreshes in BI tools.
- Dependent on IdP availability — if IdP is down, Snowflake login fails.
- Slightly more setup complexity (IdP metadata, role mappings, SCIM if provisioning).
Setup involves:
- Creating a SECURITY INTEGRATION in Snowflake
- Configuring SAML metadata in the IdP
- Mapping IdP groups to Snowflake roles
Example:
CREATE SECURITY INTEGRATION azure_ad_sso
TYPE = SAML2
ENABLED = TRUE
SAML2_ISSUER = '<entity-id>'
SAML2_PROVIDER = 'CUSTOM'
SAML2_SSO_URL = '<login-url>'
SAML2_X509_CERT = '<cert>';
3. Key Pair Authentication (Recommended for CI/CD)
This is our preferred method for service accounts or CI/CD pipelines.
Use for: Services running programmatic workloads into Snowflake (airflow jobs, github actions, dbt runs etc.)
How it works:
- Generate an RSA private/public key pair
- Assign the public key to the Snowflake user
- Store the private key securely (e.g., GitHub Secrets, AWS SSM)
ALTER USER airflow_service_user
SET RSA_PUBLIC_KEY = '<public-key-here>';
Benefits:
- Additional security with an encrypted key (passphrase)
- Long-lived keys (but rotateable)
- Secure when stored via secrets managers
Limitations:
- Not supported natively by some BI tools, or challenge to integrate (e.g., Tableau Cloud, Power BI) for live connections or refresh schedules — usually better for CLI, automation, or services.
- Keys need secure storage (e.g., secrets manager) — if compromised, attacker gets full access until rotated.
- Requires manual rotation (no built-in expiry like PATs or OAuth tokens).
4. External OAuth (SSO for Applications)
If you’ve already enabled SSO for direct user logins (see section 2), External OAuth extends that same single sign-on experience to applications like Tableau, Power BI, Looker, and custom apps — eliminating the need to store database passwords in client tools.
Use for: BI tools and apps that need to connect to Snowflake on behalf of a user, or service principals in the IdP.
Use for: Power BI, Tableau, Looker, custom apps using Snowflake connectors.
Benefits:
- Leverages the same IdP SSO policies (MFA, conditional access) as browser login
- Centralized identity control — no password sync between Snowflake and apps
- Short-lived OAuth tokens with optional refresh tokens for scheduled tasks
- Token-based access with short-lived tokens and optional refresh tokens for background tasks
Flows:
- Authorization Code Flow – interactive human login
- Client Credentials Flow – machine-to-machine (service principals in IdP)
Setup involves:
- Creating an External OAuth security integration in Snowflake
- Registering the Snowflake resource in your IdP (Okta, Azure AD, Ping, etc.)
- Mapping IdP claims (e.g., email, login name) to Snowflake users
Limitations:
- Token refresh support varies by client/tool — if BI tool can’t store/refresh tokens, service accounts may still need Key Pair or PAT.
- Requires correct claim mapping (
EXTERNAL_OAUTH_TOKEN_USER_MAPPING_CLAIM) — misconfigurations can block logins. - Dependent on IdP’s OAuth service availability.
Example:
CREATE SECURITY INTEGRATION my_ext_oauth_integration
TYPE = EXTERNAL_OAUTH
ENABLED = TRUE
EXTERNAL_OAUTH_TYPE = 'AZURE'
EXTERNAL_OAUTH_ISSUER = 'https://login.microsoftonline.com/<tenant-id>/v2.0'
EXTERNAL_OAUTH_AUDIENCE_LIST = ('https://<your-snowflake-account>.snowflakecomputing.com')
EXTERNAL_OAUTH_JWS_KEYS_URL = 'https://login.microsoftonline.com/<tenant-id>/discovery/v2.0/keys'
EXTERNAL_OAUTH_SNOWFLAKE_USER_MAPPING_ATTRIBUTE = 'LOGIN_NAME'
EXTERNAL_OAUTH_TOKEN_USER_MAPPING_CLAIM = 'upn';
5. Personal Access Tokens (PATs)
Snowflake now supports Personal Access Tokens for use with Snowflake’s REST APIs.
Use for: CLI tools, API access in short-lived scripts, option for applications service users that don’t support key pair
Benefits:
- Easier than key pairs for quick scripts
- Revocable tokens scoped per user
Limitations:
- Still in evolution; not ideal for CI/CD at scale
- Scoped to the user who generated them
Example:
-- 1. Create an authentication policy to define PAT rules
CREATE AUTHENTICATION POLICY my_authentication_policy
PAT_POLICY = (
MAX_EXPIRY_IN_DAYS = 30
);
-- 2. Assign the authentication policy to the user
ALTER USER my_user
SET AUTHENTICATION_POLICY = my_authentication_policy;
-- 3. Create (assign) a new PAT for the user
ALTER USER IF EXISTS my_user
ADD PAT my_service_token
ROLE_RESTRICTION = 'ANALYST_ROLE'
DAYS_TO_EXPIRY = 30
COMMENT = 'Token for Tableau refresh service account';
Choosing the Right Authentication Method
| Scenario |
Recommended Method |
| Human – UI access |
SSO (via IdP) + MFA
(Username + MFA only if IdP not available)
|
| Human – BI tool access |
External OAuth (via IdP SSO – Authorization Code Flow, for human users)
(Snowflake OAuth if no IdP)
|
| Service – BI tool refreshes |
External OAuth with refresh tokens (if supported by BI platform)
or Key Pair Authentication for a dedicated service account
or Personal Access Token (PAT) if key pairs aren’t supported
|
| Service – CI/CD pipelines |
Key Pair Authentication |
| Human – Manual CLI access |
Personal Access Token (PAT) (short-lived) or Key Pair |
| Service – External app integrations |
External OAuth (user-based) or Key Pair (service-based)
PAT if key pair not supported
|
Best Practices Summary
- Use SSO for human users when possible
- Use key pairs for automation (avoid hardcoded passwords)
- Rotate keys and tokens regularly
- Apply least privilege roles at the user/service level
- Monitor login history with LOGIN_HISTORY and ACCESS_HISTORY
Need help setting up secure authentication for Snowflake in your environment? Drop us a note — we’ve helped organizations implement everything from key-based CI/CD pipelines to enterprise-grade SSO.
