Sessions and Cookies
A session is a group of interactions between a user and an application that take place within a given timeframe. A single session can contain multiple activities (such as page views, events, social interactions, and e-commerce transactions), all of which the session stores temporarily while the user is connected.
By default, when a user leaves a website or closes their browser, their session ends. To keep users from having to log in every time they return, applications can extend sessions by storing session information in a cookie. Sessions end when a user logs out or when session lifetime limits are reached. Password resets cause Auth0 sessions to expire.
See the following Quickstarts for examples of session handling:
There are typically three session layers that can be created when your users log in:
Application Session Layer: This layer is the session inside your application. Though your application uses Auth0 to authenticate users, your application also tracks that the user has logged in to your application; in a regular web application, for example, you achieve this by storing this information inside a cookie.
Auth0 Session Layer: Auth0 also maintains a session on the Authorization Server for the user and stores their user information inside a cookie. This layer is used so that the next time a user is redirected to Auth0 for login the user's information will be remembered. This session layer makes the SSO experience possible for inbound SSO implementations.
Identity Provider Session Layer: When users attempt to sign in using an identity providers such as Facebook or Google, and they already have a valid sign-in (with whichever provider they choose) they will not be prompted again to sign in though they may be asked to give permission to share their information with Auth0 and, in turn, your application.
Logout in the context of Auth0 implementations is the act of terminating an authenticated session. It is a security best practice to terminate sessions when they’re no longer needed to avoid a potential takeover by unauthorized parties.
Auth0 provides tools to help you give users the ability to log out; this includes options for providing different levels of logout and also determining where the user will land after the logout is complete.
Application Session Layer Logout: Logging users out of your applications typically results in their application session being cleared, and this should be handled by your application: for the Application Session Layer, there is nothing within your Auth0 tenant that you need to use to facilitate session termination. This will require you to utilize whatever application session stack you are using to clear out any session related information. Note that some of the Auth0 SDKs do provide some support for application sessions; please check the documentation to see if there is any local SDK session removal that needs to be done.
Auth0 Session Layer Logout: You can log users out of the Auth0 session layer by redirecting them to the Auth0 Logout endpoint so Auth0 can clear the SSO cookie.
Identity Provider Session Layer Logout: It is not necessary to log the users out of this session layer, but you can use Auth0 to force the logout if required.
Logging out of your Auth0 Session Layer will require you to redirect the user to
YOUR_TENANT.auth0.com>/v2/logout - typically performed via use of the appropriate method in the Auth0 SDK for your technology stack. This will clear your Auth0 session. You will also want to add a query parameter for that request called
returnTo - this parameter should contain a URL that has been pre-registered and protects you against open redirect attacks.
Auth0 only redirects to whitelisted URLs after logout and there are two places you can configure these. The first place you can set this is at your Auth0 tenant level where you can put the set of logout URLs that are shared between all applications. The second place is in the application settings: if you need different redirects for each application, you can whitelist the URLs in your application settings. This allows you to set logout URLs in an application-specific context.
Session lifetime and session timeout
You can set the behavior in cases where a user doesn’t explicitly log out of your application. Auth0 provides for session lifetime limits to deal with Auth0 session termination in this scenario.
You can also log the users out of the identity provider session layer. While this is not recommended, for many providers, Auth0 provides this behavior by having you add the
federated query parameter to the redirect to
/v2/logout. This redirects the user to their identity provider and logs them out there as well.
Session lifetime limits determine how long the system should retain a login session. In Auth0, two settings can be configured for session lifetime:
Inactivity timeout: Timeframe after which a user's session will expire if they haven’t interacted with the Authorization Server. Will be superseded by system limits if over 3 days for self-service plans or 100 days for enterprise plans.
Require log in after: Timeframe after which a user will be required to log in again, regardless of their activity. Will be superseded by system limits if over 30 days for self-service plans or 365 days for enterprise plans.
These settings are configured on the tenant; you can configure them using either the Auth0 Dashboard or the Management API.
Application-specific logout URLs
There are two important things to consider when you use application-specific logout URLs:
You must send
client_idas a query parameter when calling the
/v2/logoutendpoint and the
returnToURL must be in the application’s list of allowed logout URLs.
This will end the Auth0 Session for the entire tenant - i.e. for all defined applications, not just the one that matches the
client_idsupplied. Passing the
client_idtells the /
logoutendpoint where to look for the logout URL white-list.
After the user logout occurs Auth0 will only redirect to a URL that is defined in this list.
If you redirect the user back to the application after logout and the application redirects to an identity provider that still has an authenticated session for that user, the user will be silently logged back into your application and it may appear that logout didn’t work. In these cases, we recommend that you have a specific logout landing page in your application so you can tell the user that they successfully logged out - and, if desired, you can also warn them that they may still be logged into their identity provider.
In the case where a user has not taken any actions that cause the Auth0 session to be updated, we recommend that you warn 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 they can continue their session without the need to be prompted again for credentials.
Inactivity Timer: Add a rolling timer to the React SDK wrapper that aligns with the maximum idle lifetime of the Auth0 session. Each time a token is returned to the application, reset the timer.
Timeout Modal: When the timer hits 60 seconds from expiration, a timeout modal should render requesting the user to logout or continue their session.
Continue the session: If the user chooses to continue their session, use the
getTokenSilently()method to request a new token without redirecting the user from the page they are currently interacting with.
Logging out: In the case, the user chooses to logout the
logout()method should be called to assure the Auth0 session is ended as well.
Idle Timeout: In the case that the idle timeout is reached no immediate action is necessary. To handle the fact that the user may still be active in another tab, the behavior should not be to log the user out.
Other options include updating the modal with a login button, using the window.onfocus event to trigger
getTokenSilently(), or redirecting the user to landing page.