In a federated environment, user authentication is separated from user access through the use of one or more external entities that provide independent authentication of user credentials. The
authentication is then passed to one or more services, enabling users to access the services through SSO. A federated environment consists of the following components:

Service provider (SP):

In a Snowflake federated environment, Snowflake serves as the SP.

Identity provider (IdP):

The external, independent entity responsible for providing the following services to the SP:

Creating and maintaining user credentials and other profile information.

Authenticating users for SSO access to the SP.

Snowflake supports most SAML 2.0-compliant vendors as an IdP; however, certain vendors include native support for Snowflake (see below for details).

When a user logs in, the behavior of the system is determined by whether the login is initiated through Snowflake or the IdP:

Snowflake-initiated login:

To log in through Snowflake:

User goes to the Snowflake web interface.

User chooses to log in using the IdP configured for your account (Okta, ADFS, or a custom IdP).

User authenticates with the IdP using their IdP credentials (e.g. email address and password).

If authentication is successful, the IdP sends a SAML response to Snowflake to initiate a session and displays the Snowflake web interface.

Note

For Snowflake-initiated login, the Snowflake login page provides two options for authentication (IdP or Snowflake). To use federated authentication, users must choose the IdP option and then enter
their credentials when prompted. Choosing the Snowflake option bypasses federated authentication and logs the user in using Snowflake’s native authentication.

IdP-initiated login:

To log in through the IdP for your account:

User goes to the IdP site/application and authenticates using their IdP credentials (e.g. email address and password).

In the IdP, user clicks on the Snowflake application (if using Okta or ADFS) or the custom application that has been defined in the IdP (if using another IdP).

The IdP sends a SAML response to Snowflake to initiate a session and then displays the Snowflake web interface.

When a user logs out, the available options are dictated by whether the IdP supports global logout or only standard logout:

Standard:

Requires users to explicitly log out of both the IdP and Snowflake to completely disconnect. All IdPs support standard logout.

Global:

Enables a user to log out of the IdP and subsequently all their Snowflake sessions. Support for global logout is IdP-dependent.

In addition, the behavior of the system is determined by whether the logout is initiated through Snowflake or the IdP:

Snowflake-initiated logout:

Global logout is not supported from within Snowflake, regardless of whether the IdP supports it. When a user logs out of a Snowflake session, they are logged out of that session only. All their other
current Snowflake sessions stay open, as does their IdP session. As a result, they can continue working in their other sessions or they can initiate additional sessions without having to
re-authenticate through the IdP.

To completely disconnect, users must explicitly log out of both Snowflake and the IdP.

IdP-initiated logout:

When a user logs out through an IdP, the behavior depends on whether the IdP supports standard logout only or also global logout:

ADFS supports both standard and global logout. If global logout is enabled, the ADFS IdP login page provides an option for signing out from all sites that the user has accessed. Selecting this option
and clicking Sign Out logs the user out of ADFS and all their Snowflake sessions. To access Snowflake again, they must re-authenticate using ADFS.

Okta supports standard logout only. When a user logs out of Okta, they are not automatically logged out of any of their active Snowflake sessions and they can continue working. However, to initiate
any new Snowflake sessions, they must authenticate again through Okta.

All custom providers support standard logout; support for global logout varies by provider.

Note

For a web-based IdP (e.g. Okta), closing the browser tab/window does not necessarily end the IdP session. If a user’s IdP session is still active, they can still access Snowflake until the IdP
session times out.

When a user’s session times out, the behavior is determined by whether it is their Snowflake session or IdP session that timed out:

Snowflake timeout:

If a users logs into Snowflake using SSO and their Snowflake session expires due to inactivity, the Snowflake web interface is disabled and the prompt for IdP authentication is displayed:

To continue using their expired Snowflake session, the user must authenticate again through the IdP.

The user can exit the session by clicking the Cancel button.

The user can also go to the IdP site/application directly and relaunch Snowflake, but this initiates a new Snowflake session.

IdP timeout:

After a specified period of time (defined by the IdP), a user’s session in the IdP automatically times out, but this does not affect their Snowflake sessions. Any Snowflake sessions that are active at
the time remain open and do not require re-authentication. However, to initiate any new Snowflake sessions, the user must log into the IdP again.