Snowflake Authentication and MFA

Authentication answers one question: who is knocking at the door? Roles and grants decide what that person may do after entry, and authentication decides whether entry happens at all. Strong sign-in methods stop most account takeovers before they start.

Sign-In Methods at a Glance

Think of a building with several kinds of entrances. A front desk checks visitor badges. Staff swipe company cards. Delivery robots carry digital keys. Snowflake offers matching options for people, applications, and automated jobs.

AUTHENTICATION OPTIONS
======================

METHOD              WHO USES IT               STRENGTH
------------------  ------------------------  ----------------------
Username + password People, basic setup       Weak alone
Password + MFA      People                    Strong
SSO (SAML 2.0)      Company employees         Strong, central control
Key pair (RSA)      Applications, pipelines   Strong, no password
OAuth               Tools and apps            Strong, token based
Programmatic access Scripts and automation    Strong, expires
token

Multi-Factor Authentication

Multi-factor authentication, called MFA, asks for two proofs: something you know and something you have. A password supplies the first proof. An authenticator app, a passkey, or a security key supplies the second. A stolen password alone no longer opens the door.

SIGN-IN WITH MFA
================

 User types password  --->  Snowflake checks it
                                  |
                                  v
                       Prompt for second factor
                       (approval on phone or passkey)
                                  |
                                  v
                          Access granted

Snowflake strongly recommends MFA for every person who signs in with a password and increasingly requires it. Users enroll from their profile in Snowsight. Administrators can mandate enrollment through an authentication policy.

Single Sign-On

Single sign-on, called SSO, lets employees use their company identity provider, such as Okta or Microsoft Entra ID, to enter Snowflake. One login covers many tools. Administrators disable a departing employee once, and every connected tool locks automatically. Snowflake supports SAML 2.0 federation for SSO.

Key Pair Authentication for Automation

Scripts and pipelines should never store a human password. Key pair authentication uses a matched pair of files. The private key stays with the application. The public key lives on the Snowflake user.

-- Generate keys on your computer (terminal commands)
-- openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8 -nocrypt
-- openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub

-- Create a service user that signs in with the key only
CREATE USER etl_service
  TYPE           = SERVICE
  DEFAULT_ROLE   = ETL_ROLE
  RSA_PUBLIC_KEY = 'MIIBIjANBgkqh...';

-- Rotate by adding a second key before removing the old one
ALTER USER etl_service SET RSA_PUBLIC_KEY_2 = 'MIIBIjANBgkqh...';

The TYPE = SERVICE setting marks the user as non-human, so password and MFA prompts never apply. Store the private key in a secrets manager and never in a code repository.

Authentication Policies

An authentication policy states which methods an account or user may use. Policies close doors that nobody needs.

CREATE AUTHENTICATION POLICY staff_policy
  AUTHENTICATION_METHODS = ('SAML', 'PASSWORD')
  MFA_ENROLLMENT         = REQUIRED
  COMMENT = 'Staff sign in with SSO or password plus MFA';

-- Apply to the whole account
ALTER ACCOUNT SET AUTHENTICATION POLICY = staff_policy;

-- Apply a different policy to one user
ALTER USER etl_service SET AUTHENTICATION POLICY = service_policy;

User Types

USER TYPE        PURPOSE                          PASSWORD ALLOWED
---------------  -------------------------------  ----------------
PERSON           Humans using Snowsight or tools  Yes, with MFA
SERVICE          Applications and pipelines       No
LEGACY_SERVICE   Older tools needing passwords    Yes, discouraged

Good Habits

• Enable SSO for all employees and disable direct passwords where possible.
• Require MFA for every administrator without exception.
• Give each application its own service user with a key pair.
• Rotate keys on a schedule and revoke unused users promptly.
• Review the LOGIN_HISTORY view for failed or unusual sign-ins.

SELECT user_name, client_ip, first_authentication_factor,
       second_authentication_factor, is_success, error_message
FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
WHERE event_timestamp >= DATEADD('day', -7, CURRENT_TIMESTAMP())
  AND is_success = 'NO'
ORDER BY event_timestamp DESC;

A Practical Scenario

A growing company starts with five analysts who share one password. A departing employee keeps access for weeks because nobody notices. The security lead connects Snowflake to the company identity provider, enrolls every administrator in MFA, and creates separate service users with key pairs for each pipeline. Employee departures now end access automatically, and every pipeline run appears under its own user name in the login history.

Frequently Asked Questions

What happens when a user loses the MFA device?

An administrator with the proper role can remove the enrolled device so the user enrolls a new one. Document that process before the first request arrives.

Can one user sign in with several methods?

Authentication policies define the allowed methods for each user or account, so teams can combine or restrict them as needed.

Key Points

• Authentication proves identity; roles and grants control permissions afterward.
• MFA adds a second proof and blocks most stolen password attacks.
• SSO centralizes employee access through the company identity provider.
• Key pair authentication suits applications and removes passwords from scripts.
• Authentication policies restrict allowed methods at account or user level.
• LOGIN_HISTORY reveals failed and suspicious sign-in attempts.