Native to Web SSO and Sessions

When a WebView or browser initiates a call to the /authorize endpoint, Auth0 determines if there is an active session, and then either reuses the existing session or honors the provided session_transfer_token. To avoid session injection risks, Auth0 uses a safe and predefined evaluation to determine if the session_transfer_token is valid. To learn more, read Configure and Implement Native to Web SSO.

Specific Native to Web SSO flows can result in the following behaviors:

1. The user is logged in when a valid session_transfer_token is sent and there is no pre-existing Auth0 session.

2. The user is logged in when a valid session_transfer_token is sent and a pre-existing Auth0 session is found for the same user. 

3. The user is prompted to login when a pre-existing Auth0 session is found and the session_transfer_token belongs to a different user. Additionally, the pre-existing Auth0 session is revoked.

4. The user is prompted to log in when a pre-existing Auth0 session is found and the session_transfer_token is invalid. 

A session_transfer_token is used to initiate a secure session in a WebView or browser to securely authenticate the user without being prompted to login. These web sessions may also issue their own refresh tokens. 

Native to Web SSO applies a set of revocation rules to ensure consistent and secure behavior when sessions and refresh tokens are revoked: 

• When a refresh token is revoked, it also revokes its associated refresh tokens and sessions if enforce_cascade_revocation is enabled in the native application.

• When a web session is revoked, it also revokes its associated refresh tokens  if enforce_online_refresh_tokens  is enabled in the web application

• Nested Native to Web SSO is not allowed. A web session created using a session_transfer_token cannot generate another session_transfer_token.