Managing/Using federated authentication¶

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.

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

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.

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

• Go driver version 1.6.15 (or later)

• JDBC driver version 3.12.8 (or later)

• Node.js driver version 1.12.0 (or later)

• ODBC driver version 2.21.2 (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;
   

   Copy

   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]"
     

     Copy

     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]"
     

     Copy

   • For the Snowflake JDBC Driver, see Adding the JNA classes to your classpath.

Upgrading to Okta Identity Engine¶

If you are upgrading from Okta Classic to Okta Identity Engine for native SSO, you need to update your Snowflake client drivers before the upgrade.

If you encounter HTTP 429 errors after your upgrade, you have most likely hit the rate limit enforced by the authentication endpoint used by the latest client drivers. For details, refer to HTTP 429 errors (in this topic).

HTTP 429 errors¶

The Okta Identity Engine requires communication through its authentication endpoint (/api/v1/authn), which currently has a rate limit of 20 requests per user per 5 seconds. To support the Okta Identity Engine, the latest Snowflake client drivers use this Authentication endpoint, and are therefore subject to the rate limit. If this limit is prohibitive, contact Okta Support to increase the rate limit of the authentication endpoint.

Snowflake client drivers switched to the authentication endpoint in the following versions:

• Go: 1.6.20

• JDBC: 3.13.22

• .NET: 2.0.20

• Node.js: 1.6.21

• ODBC: 2.25.5

• Python: 2.7.12

• SnowSQL: 1.2.24

• SQLAlchemy: 1.4.6