Managing/Using Federated Authentication

This topic describes how to manage and use federated authentication once it has been configured.

In this Topic:

Managing Users with Federated Authentication Enabled

Managing Snowflake User Passwords

With federated authentication enabled for your account, Snowflake still allows maintaining and using Snowflake user credentials (login name and password). In other words:

  • Account and security administrators can still create users with passwords maintained in Snowflake.

  • Users can still log into Snowflake using their Snowflake credentials.

However, if federated authentication is enabled for your account, Snowflake does not recommend maintaining user passwords in Snowflake. Instead, user passwords should be maintained solely in your IdP.

If you create a user with no password (or alter an existing user and remove their password), this effectively disables Snowflake authentication for the user. Without a password in Snowflake, a user cannot log in using Snowflake authentication and must use federated authentication instead. Note that you cannot use the Snowflake web interface to create users with no passwords or remove passwords from existing users. You must use CREATE USER or ALTER USER.

Specifically, we recommend that you disable Snowflake authentication for all non-administrator users.


The MUST_CHANGE_PASSWORD user property does not apply for federated authentication and should not be used. In particular, if you choose to not maintain passwords in Snowflake for users, ensure this property is set to FALSE for these users.

Also, you must maintain at least one Snowflake account administrator with a Snowflake password. This ensures that an account administrator can access Snowflake at all times to manage federated authentication and troubleshoot any issues that occur.

Disabling and Dropping Users

As an account or security administrator in Snowflake, you may find it necessary to drop or, more likely, disable a user. Users who are dropped or disabled in Snowflake are still able to log into their Okta accounts, but they will receive an error message when they attempt to connect to Snowflake. You must recreate or enable the user before they can log in.

You can drop/create and disable/enable users using either the Snowflake web interface or the equivalent SQL commands.

Using SSO with Command Line Clients

With an IdP (Okta, ADFS, or any of the other supported SAML 2.0-compliant services/applications) configured for your account, Snowflake supports using SSO to connect and authenticate with the following Snowflake-provided clients:


v1.1.43 or higher

Python Connector

v1.4.8 or higher

JDBC Driver

v3.2.7 or higher

ODBC Driver

v2.13.11 or higher

Snowflake supports two methods of authenticating:

  • Browser-based SSO

  • Programmatic SSO (only for Okta)


When using SSO with command line clients, users must enter their login credentials when prompted; however, for security reasons, these credentials are never processed through the client. Instead, the credentials are sent to the IdP for authentication and the IdP sends back a valid SAML response which enables the client to initiate a Snowflake session.

Browser-based SSO

If users have the required version (or higher) of the clients installed, they can use browser-based SSO to log into Snowflake. Browser-based SSO uses the following workflow:

  1. The default web browser in their operating system launches or opens a new tab/window, displaying the authentication page for the IdP.

  2. The user enters their IdP credentials (username and password).

  3. If the user is enrolled in MFA (multi-factor authentication) in Snowflake, they are prompted to type the MFA passcode (sent from another device) or confirm the authentication (on the other device).

  4. After the IdP has authenticated their credentials, the browser displays a success message. They can then close the browser tab/window (it does not need to be open after authentication), return to the terminal window for the client, and use the Snowflake session that has been initiated.

To enable browser-based SSO, set the authenticator login parameter/option to externalbrowser for the client. For example:


--authenticator externalbrowser (when starting the client)


authenticator='externalbrowser' (when instantiating the connection)


authenticator=externalbrowser (when defining the connection string for the driver)

ODBC (Linux/macOS)

authenticator=externalbrowser (in the odbc.ini file)

ODBC (Windows)

Use regedit to set the value in the Windows Registry.


authenticator=externalbrowser (when defining the connection string for the driver)


This feature is only supported in terminal windows that have web browser access. For example, a terminal window on a remote machine accessed through a SSH (Secure Shell) session may require additional setup to open a web browser.

Native SSO — Okta Only

If Okta is your IdP, Snowflake also supports authenticating natively through Okta. This authentication method is useful when you are using SSO with a client that doesn’t have access to a web browser (e.g. connecting programmatically through the Python connector or either the JDBC or ODBC driver).

To enable native SSO through Okta, set the authenticator login parameter/option for the client to the Okta URL endpoint (provided by Okta), typically in the form of https://<your_okta_account_name> For example:


--authenticator https://<your_okta_account_name> (when starting the client)


authenticator='https://<your_okta_account_name>' (when instantiating the connection)


authenticator=https://<your_okta_account_name> (when defining the connection string for the driver)

ODBC (Linux/macOS)

authenticator=https://<your_okta_account_name> (in the odbc.ini file)

ODBC (Windows)

Use regedit to set the value in the Windows Registry.


authenticator=https://<your_okta_account_name> (when defining the connection string for the driver)

Using SSO with MFA

Snowflake supports using MFA in conjunction with SSO to provide additional levels of security:

  • Individual users in Snowflake can enroll in MFA. If a Snowflake user is enrolled in MFA and uses SSO to connect, the MFA login workflow is initiated within the SSO workflow and is required to successfully complete the authentication. For more information about MFA in Snowflake, see Multi-Factor Authentication (MFA).


    To connect through Okta SSO with MFA, Snowflake requires using browser-based SSO. If you are using native SSO for Okta, MFA is not supported.

  • In addition, your IdP may also support MFA, but this is separate from MFA in Snowflake and must be configured separately through your IdP. If MFA is enabled for your IdP, the IdP determines the workflow. To determine whether your IdP supports MFA and how it is implemented, see the documentation for your IdP.

Using SSO with Multiple Audience Values

Snowflake supports multiple audience values (i.e. Audience or Audience Restriction Fields) in the SAML 2.0 assertion from the identity provider to Snowflake.

This functionality allows customers to include URLs for more than one account, such as an AWS PrivateLink URL and a non-AWS PrivateLink URL. Snowflake accepts the account domain names for the audience values.

Currently, Snowflake supports and accepts up to four different audience values. No configuration is necessary in Snowflake. If it is necessary to include more than four audience values, please contact Snowflake Support.

For help in configuring SAML 2.0 audience values, please contact your organization’s identity provider administrator.