Manage Multi-Site Sessions with Auth0 SDK

This workflow shows how the auth0-spa-js SDK should be implemented to support multi-site session management. In this scenario, it is assumed that the tenant SSO Inactivity Timeout is set to 300 seconds, and the ID Token Expiration of each SPA application is set to 150 seconds. This is considered a "short-lived" session.

For all methods of retrieving an ID Token or Access Token, the SDK manages all the intricacies of the Proof Key for Code Exchange workflow. No additional effort or configuration is needed for this to work.

To improve the user experience the SDK includes an appState parameter for the loginWithRedirect() method. Details about the current app are packaged as part of the request to the Auth server that will be returned upon successful authentication. Allowing a seamless continuation of the user journey.

In the Quickstart, the PrivateRoute component sets a state parameter of targetUrl and the onRedirectCallback function of index.js unpacks this value to redirect the user when authentication is complete.

To keep the returned tokens stored in the safest manner possible all tokens are placed into a local cache. The ID and Access Tokens are stored as pairs with the audience and scope values being used to retrieve the tokens as needed.

Additionally the cache tokens are removed once either the ID Token or Access Token expires so that if a token is in the cache it can be assumed to stil be valid.

The getTokenSilently() method is used to leverage the token cache first, and if none exists, will launch an invisible iframe to retrieve a new token. For this purpose all requests to APIs can use this method to construct the bearer token header without the need for additional logic to handle for expired tokens.

In the Quickstart, the ExternalService view makes a request to the express API using this feature.

In the case where a user has not taken any actions that would cause the Auth0 session to be updated, Auth0 recommends that you raise a warning to the user to choose to explicitly continue their session.

The intent of this approach allows the session to go inactive if the user is no longer present, but otherwise provides a means to trigger the silent token refresh so that the can continue their session without the need to be prompted again for credentials.

To learn more about inactivity timers and timeout modals, read Application-specific logout URLs.

1. Initial Authentication

2. Maintaining Auth0 Session

3. Seamless SSO

4. Prompting user to extend session

5. User explicitly logs out of application

6. User returns to initial app after logging out

1. New tab is opened

2. Requests to login

3. User enters credentials

4. SSO cookie (with expiration) is set

5. Token exchange performed

1. User requests data from protected resource

2. getTokenSilently() called

3. Resource retrieved

4. User updates data from protected resource

5. getTokenSilently() called

   1. Iframe opened

   2. Token exchange performed

6. Resource is updated

1. User navigates to a private route

2. Check with isAuthenticated()

3. If false, loginWithRedirect()

1. At 240 seconds prompt user with keep session alive with modal that lasts 60 seconds

2. If they choose to maintain session, getTokenSilently()

1. User chooses to logout

2. logout() called

   1. Token cache cleared

   2. Call /oidc/logout

   3. Clear SSO cookie & delete session data

   4. Redirect user to logout page

1. User requests data from protected resource

2. getTokenSilently() called

3. Application-dependent behavior

Auth0 supports long-lived sessions for enterprise plans. With long-lived sessions, you can configure session limits with up to 100 days of inactivity (idle timeout) and up to one year in total duration (absolute timeout). If you have quarterly, monthly, or other timelines, this allows you to reduce friction for end-users and provide access to low-risk content and capabilities. In addition, media companies can leverage long-lived sessions for improving user experiences through seamless access to content. You can also make the choices between long-lived sessions and password validation based on your requirements around user experience and security.

Workflow details would change in the case of a long-lived session where the application session would most likely be shorter than the Single Sign-on (SSO) session.

To learn more, read Configure Session Lifetime Limits and Update Access Token Lifetime.

• Troubleshoot Invalid Token Errors
• Check API Calls