Authentication — MFA, SSO, OAuth, Key-Pair

Micro-Concept 1: The Four Authentication Methods to Know

The C03 tests recognition. You see a scenario, you pick the method. Learn the table below until you can answer in a few seconds.

The standard exam pairings:

• Service account / ETL / CI/CD → Key-pair authentication.
• Enterprise user signing in through the corporate IdP → SSO/SAML.
• BI tool, partner app, or anything that needs delegated user access → OAuth.
• Interactive password user → MFA (mandatory on most accounts now).

Micro-Concept 2: MFA, What’s Mandatory Now

Snowflake is partway through a three-phase rollout that ends single-factor password authentication for good. The phases, taken from the official deprecation timeline:

• Phase 1 (Sept 2025 – Jan 2026): MFA enforced for Snowsight logins by password users.
• Phase 2 (May 2026 – Jul 2026): All newly created human users must use MFA. No new LEGACY_SERVICE users can be created.
• Phase 3 (Aug 2026 – Oct 2026): All existing human users must use MFA for any password-based login. All service users must use key-pair, OAuth, PAT, or WIF. LEGACY_SERVICE fully deprecated.

The end state, as of October 2026:

• Human users (TYPE = PERSON or NULL): Password sign-in requires MFA. Single-factor passwords are blocked.
• Service users (TYPE = SERVICE): No password allowed at all. Must use key-pair, OAuth, PAT, or WIF.
• LEGACY_SERVICE: Transitional bucket for services that still need a password. Going away.
• Reader accounts, trial accounts, and Snowflake Postgres are out of scope for this rollout.

MFA second-factor options:

• Passkey (FIDO2 / WebAuthn): Snowflake’s recommended option on modern devices.
• Authenticator app (TOTP): Google Authenticator, Microsoft Authenticator, Authy.
• Duo Push: historically the default, still supported.

Enable MFA on a user, then enforce it with an authentication policy:

-- Inspect users' MFA enrollment
SHOW USERS;
-- Look for HAS_MFA, HAS_PASSWORD, HAS_RSA_PUBLIC_KEY columns

-- An authentication policy that requires MFA for password users
CREATE AUTHENTICATION POLICY require_mfa_pol
  AUTHENTICATION_METHODS = ('PASSWORD', 'SAML')
  MFA_ENROLLMENT = 'REQUIRED'
  MFA_POLICY = (ENFORCE_MFA_ON_EXTERNAL_AUTHENTICATION = 'ALL');

-- Apply it at the account level (or attach to a specific user)
ALTER ACCOUNT SET AUTHENTICATION POLICY require_mfa_pol;

One naming change to know. The older parameter MFA_AUTHENTICATION_METHODS is being replaced by MFA_ENROLLMENT and ENFORCE_MFA_ON_EXTERNAL_AUTHENTICATION. Both names appear in C03 questions, so recognize either form.

Micro-Concept 3: Key-Pair Authentication, the Service-Account Standard

Whenever a stem describes a service account, ETL job, or CI/CD pipeline, key-pair is the answer. The flow has four steps:

1. Generate a 2048-bit (or larger) RSA key pair. Two files: rsa_key.p8 (private) and rsa_key.pub (public).
2. Register the public key on the Snowflake user via ALTER USER … SET RSA_PUBLIC_KEY = '<contents>'.
3. The client (driver, SDK, SnowSQL, Snowpark) signs a JWT with the private key. Snowflake validates the signature using the registered public key.
4. No password is sent. No password is required. That is the trap.

-- On the user object
ALTER USER etl_service_user
  SET RSA_PUBLIC_KEY = 'MIIBIjANBgkqhkiG9w0...';

-- Optional: a second key for zero-downtime rotation
ALTER USER etl_service_user
  SET RSA_PUBLIC_KEY_2 = 'MIIBIjANBgkqhkiG9w0...';

-- Inspect
DESC USER etl_service_user;
-- Look for RSA_PUBLIC_KEY_FP and RSA_PUBLIC_KEY_2_FP (fingerprints)

Four facts to know:

• Key-pair authentication does NOT require a password. This is the most common trap on the topic. The private key signs a JWT. That JWT is the entire credential.
• Two public-key slots exist (RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2) so you can rotate keys with zero downtime. Register the new key in the second slot, switch clients over, then remove the old key.
• The private key can be encrypted with a passphrase. That passphrase is a local secret on the client machine. It is not a Snowflake credential and Snowflake never sees it.
• For TYPE = SERVICE users, key-pair (or OAuth / PAT / WIF) is required. Passwords are not an option for service users.

On a recent client project, every pipeline service account uses key-pair. The pattern that scales cleanly: generate the key pair in a secrets manager. Register the public key on a dedicated TYPE = SERVICE user. Rotate quarterly using the second slot. Anyone who hardcoded passwords two years ago is now scrambling to migrate before the October 2026 deadline.

Micro-Concept 4: SSO/SAML and OAuth, Different Problems

People mix SSO/SAML and OAuth up because both involve external identity providers. They solve different problems.

SSO/SAML is about authentication. You sign in to your corporate IdP (Okta, Microsoft Entra ID, Google Workspace). The IdP issues a SAML assertion to Snowflake saying “this is Alice.” Snowflake trusts the assertion because the IdP is configured as a SAML security integration, and lets Alice in. Snowflake never sees Alice’s password.

• Setup: CREATE SECURITY INTEGRATION … TYPE = SAML2.
• Where it shines: Enterprises with central identity management. One credential gets a user into Snowflake, Slack, GitHub, and the rest of the corporate stack.
• MFA: By default, SSO users do not trigger Snowflake MFA. Snowflake relies on the IdP to enforce strong authentication. For defense-in-depth, layer Snowflake MFA on top using an authentication policy with ENFORCE_MFA_ON_EXTERNAL_AUTHENTICATION = 'ALL'.

OAuth is about authorization delegation. A third-party tool (Tableau, Power BI, a partner app) needs to query Snowflake on a user’s behalf. OAuth issues that tool a scoped access token. The tool never sees the user’s password, and the token can be revoked independently of the user account.

• Two flavors:
  • Snowflake OAuth: Snowflake itself is the authorization server, issuing tokens via CREATE SECURITY INTEGRATION … TYPE = OAUTH.
  • External OAuth: tokens come from an external authorization server (Okta, Azure AD, PingFederate, custom IdP) and Snowflake validates them.
• Where it shines: BI tools (Tableau, Power BI, Looker), data apps, partner integrations, and Snowpark sessions. Anywhere you want token-based access instead of stored credentials.

The shortest way to keep them separate: SSO/SAML is for humans logging in. OAuth is for tools acting on behalf of humans.

Micro-Concept 5: Account Identifiers, Two Formats, One Recommended

Every Snowflake account has two identifiers. The exam asks which one is recommended and why.

Both formats work for connecting today. The reason orgname-accountname is the recommended form is operational stability. Replication and failover flip an account between regions, and connection strings that depend on the locator break the moment that happens. Production drivers, JDBC URLs, and BI tool configurations should all use the org-name form. The locator is fine for a one-off worksheet, but never for anything you want to survive a region migration.

-- See both forms for your current account
SELECT
  CURRENT_ORGANIZATION_NAME() || '-' || CURRENT_ACCOUNT_NAME() AS preferred_id,
  CURRENT_ACCOUNT()                                            AS locator_form,
  CURRENT_REGION()                                             AS region;

Micro-Concept 6: LOGIN_HISTORY, Auditing Authentication

The audit trail for who logged in, how, and from where lives in SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY. Retention is 365 days, and per the official view documentation, latency is up to 120 minutes. For real-time auditing, the corresponding INFORMATION_SCHEMA.LOGIN_HISTORY() table function holds 7 days of data with near-zero latency.

-- Last 20 logins, with the auth method used
SELECT event_timestamp, user_name, client_ip, reported_client_type,
       first_authentication_factor, second_authentication_factor,
       is_success, error_code, error_message
FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
ORDER BY event_timestamp DESC
LIMIT 20;

Two columns matter on the exam:

• FIRST_AUTHENTICATION_FACTOR: values include PASSWORD, SAML_ASSERTION, OAUTH_ACCESS_TOKEN, RSA_KEYPAIR, and so on.
• SECOND_AUTHENTICATION_FACTOR: values are DUO, TOTP, WEBAUTHN (passkey), or null if no second factor was used.

This is the source of truth for “did MFA actually fire?” and “is anyone still using single-factor password?” Filter for first_authentication_factor = 'PASSWORD' AND second_authentication_factor IS NULL and you have your remediation list before the deprecation deadlines hit.

Official docs for today’s topics.

Account identifiers, password deprecation, OAuth.