# 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¶

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.

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.

Important

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 Client Applications That Connect to Snowflake¶

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:

SnowSQL

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

.NET Driver

v1.0.13 or higher

Node.js Driver

v1.6.0 or higher (for browser-based SSO); v1.6.1 or higher (for native SSO authentication through Okta)

Snowflake supports two methods of authenticating:

• Browser-based SSO

• Programmatic SSO (only for Okta)

Important

When using SSO with client applications that connect to Snowflake, 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 Snowflake-provided clients installed, they can use browser-based SSO to log into Snowflake.

#### How Browser-based SSO Works¶

When a client application is configured to use browser-based SSO, the application uses the following workflow for user authentication:

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

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 the user’s credentials, the browser displays a success message. The user can then close the browser tab/window (it does not need to be open after authentication), return to the application, and use the Snowflake session that has been initiated.

#### Requirements For Using Browser-based SSO¶

With browser-based SSO, the Snowflake-provided client (for example, the Snowflake JDBC driver) needs to be able to open the user’s web browser. For this reason, the Snowflake-provided client and the client application that uses it need to be installed on the user’s machine. Browser-based SSO does not work if the Snowflake-provided client is used by code that runs on a server.

#### Setting Up Browser-based SSO¶

To set up browser-based SSO for authentication, set the authenticator login parameter/option to externalbrowser for the client.

Client

Instructions

SnowSQL

Specify the command line flag --authenticator externalbrowser when starting the client.

Python

Pass authenticator='externalbrowser' to the snowflake.connector.connect() function.

JDBC

Set authenticator=externalbrowser in the connection string for the driver.

ODBC (Linux/macOS)

Set authenticator=externalbrowser in the odbc.ini file.

ODBC (Windows)

In the ODBC Data Source Administrator tool, edit the DSN for Snowflake and set Authenticator to externalbrowser.

.NET

Set authenticator=externalbrowser in the connection string for the driver.

Node.js

Set the authenticator=EXTERNALBROWSER option when calling the snowflake.createConnection function.

#### Using Connection Caching to Minimize the Number of Prompts for Authentication — Optional¶

Whenever a client application establishes a new connection to Snowflake, the user is prompted for authentication. This can result in multiple prompts for authentication if the client application establishes a connection multiple times.

To minimize the number of times that a user is prompted for authentication, the account administrator can enable connection caching.

When connection caching is enabled, the client application stores a connection token for use in subsequent connections. For security, the connection token is stored in the keystore for the operating system. Before you enable connection caching, consult with your security team to determine if this complies with your security policies.

Tip

Connection caching can be combined with MFA token caching.

For more information on how to combine these two features, see Using MFA Token Caching to Minimize the Number of Prompts During Authentication — Optional.

Snowflake supports connection caching with the following drivers and connectors on macOS and Windows (currently, this feature is not supported on Linux):

• ODBC driver version 2.21.2 (or later)

• JDBC driver version 3.12.8 (or later)

• Snowflake Connector for Python 2.2.8 (or later)

To enable connection caching:

1. Set the account-level parameter ALLOW_ID_TOKEN to true:

alter account set allow_id_token = true;


Note

You must be an account administrator (i.e. a user with the ACCOUNTADMIN role) to enable connection caching.

2. Add the package or libraries needed by the driver or connector:

• If you are using the Snowflake Connector for Python, install the optional keyring package by running:

pip install "snowflake-connector-python[secure-local-storage]"


You must enter the square brackets ([ and ]) as shown in the command. The square brackets specify the extra part of the package that should be installed.

Use quotes around the name of the package as shown to prevent the square brackets from being interpreted as a wildcard.

If you need to install other extras (for example, pandas for using the Python Connector APIs for Pandas), use a comma between the extras:

pip install "snowflake-connector-python[secure-local-storage,pandas]"

• For the Snowflake JDBC Driver, see Adding the JNA Classes to Your Classpath.

### 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 for your Okta account (provided by Okta), typically in the form of https://<okta_account_name>.okta.com:

Client

Instructions

SnowSQL

Specify the command line flag --authenticator https://<okta_account_name>.okta.com when starting the client.

Python

Pass authenticator='https://<okta_account_name>.okta.com' to the snowflake.connector.connect() function.

JDBC

Set authenticator=https://<okta_account_name>.okta.com in the connection string for the driver.

ODBC (Linux/macOS)

Set authenticator=https://<okta_account_name>.okta.com in the odbc.ini file.

ODBC (Windows)

In the ODBC Data Source Administrator tool, edit the DSN for Snowflake and set Authenticator to https://<okta_account_name>.okta.com.

.NET

Set authenticator=https://<okta_account_name>.okta.com in the connection string for the driver.

Node.js

Set the authenticator option to https://<okta_account_name>.okta.com when calling snowflake.createConnection.

## 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).

Note

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.

• With certain Snowflake-provided clients, you can cache MFA tokens for up to four hours. For more information, see Using MFA Token Caching to Minimize the Number of Prompts During Authentication — Optional.

## 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 supports the URLs to access Snowflake as audience values. The URLs for multiple Snowflake accounts are supported because each account has a unique account name and a unique URL to access Snowflake. Additionally, Snowflake accepts the account domain names and the URLs to access Snowflake using AWS PrivateLink or Azure Private Link as audience values. For more details on SSO and avoiding the public Internet, see Using SSO with Private Connectivity (in this topic).

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.

## Using SSO with Private Connectivity¶

Snowflake supports SSO with private connectivity using AWS PrivateLink and Azure Private Link.

Currently, for any given Snowflake account, SSO works with only one account URL at a time: either the public account URL or the URL associated with the AWS PrivateLink or Azure Private Link service.

However, if you are participating in the Organizations preview, you can use the corresponding account URL in the SAML2 security integration. For more information, see Advanced SAML SSO Features.

Important

To use SSO with either AWS PrivateLink or Azure Private Link, you must contact Snowflake Support and provide the account URL to use with the AWS PrivateLink or Azure Private Link service.