Docs

Logout

Logout

Logout is the act of terminating an authenticated session when it's no longer needed, thus minimizing the likelihood that unauthorized parties can "take over" the session. This is typically achieved by provisioning a logout option on the user interface you provide to your users. Multiple types of sessions can be created when a user logs in (e.g., local application sessions, Auth0 session, third-party Identity Provider sessions), and you will need to determine which of these sessions need to be terminated when the user clicks any Logout option.

Best Practice

Your logout behavior should make it clear to a user which session(s) are being terminated, and ideally, will display a visual confirmation of logout afterward.

When configuring logout behavior, you'll need to consider:

  • Which sessions should be terminated when the user initiates logout?
  • What information should you provide to users as confirmation of the sessions terminated?
  • Where should users be redirected to after logout completes?
  • How long do you want sessions to last in the event that users do not trigger the logout process?
  • Should the End User be logged out of all of their application sessions when they log out of one?
  • Should the session with an organization's IDP also be terminated at logout?

Given the varying types of sessions that can be created whenever a user logs in, there are several types of logout possible. Local application logout ends the session with the application, whereas Auth0 logout terminates the Auth0 session. If you have organizations that are using their own IDP, you may want to consider a Federated Logout strategy and implement accordingly. Global, or Single Logout (SLO), ends the Auth0 session and also sends a logout request/notice to applications relying on the Auth0 session.

The functionality provided by your application, as well as your use of features like Single Sign-on (SSO), will inform your decision as to what type of logout is required and what visual confirmation you'll need to provide to your users. Regardless of which option you choose, the logout process you implement should make it clear to the user which sessions are being terminated, and also when the logout process has completed.

If the logout feature in one application terminates an Auth0 SSO session that is used by other applications, the user may lose work if they have uncommitted transactions. Be sure to add the functionality needed to handle such conditions to minimize the likelihood of lost work.

In some situations, a user may be expected to logout of all associated applications when they log out of any one of the applications you provide. This is something that can add complexity. However if you have concerns that users could leave themselves vulnerable (perhaps due to data sensitivity or the like), then you will likely need to review Single Logout and implement accordingly.

Where to send users after logout

Once your user logs out, they will be redirected to a specific location of your choosing. This location is specified as the logout redirect URL, and you can define this as a parameter via the Auth0 Dashboard.

The URL(s) you use to redirect users after logging out must be whitelisted in the Dashboard to mitigate open-redirect security vulnerabilities. You can whitelist them at the tenant or application levels.

If the user logs out and you redirect them back to the application, and the application redirects to an Identity Provider that still has a valid session for the user, the user will be logged in silently to the application. This may appear to the user as if the logout process didn't function properly.

Automatic termination of sessions

Not all users will trigger the logout process manually, so Auth0 also provides session timeout to prevent overly long-lived sessions. This setting is available and configurable via the Auth0 Dashboard.

Get Started with Auth0 Video

Watch this short video Logout to learn about different kinds of logout behavior and different session layers. Learn how to configure callback URLs in the application and tenant settings in the Dashboard.

Single Logout

If you are doing Federated Logout you will likely also want to do Single Logout (SLO), and there are two main approaches you can take.

SLO can add complexity to your system, so you need to ensure that you really need it before adding the extra development and maintenance time to your system.

Short-lived tokens

Best Practice

You want to avoid making too many calls to your Auth0 tenant to avoid rate limiting and poor performance. A best practice is to only request new tokens if tokens have expired and a user takes an action. This will avoid applications that are simply open, but not in use, from continually polling for new tokens.

This is by far the simplest approach to Single Logout. Each application enforces a short time within which a user can use the system, say, 5-10 minutes. On each action a user performs, if the time has expired then either a redirect to Auth0 (for regular web apps), or Silent Authentication for client side Single Page Applications will be used to obtain new tokens. Ordinarily new tokens will be issued silently due to the Single Sign On (SSO) session. However, after logout, all applications will fail to get new tokens silently because the SSO session will have been removed, and the user will need to re-enter their credentials.

If you are automatically forwarding the user directly to their own IdP as part of an enterprise connection using the connection parameter, this can break this technique unless you are also doing Federated Logout

Build a logout service

Another technique you can use is to build a logout service that can track and destroy application sessions. Each application would notify the logout service when it creates and removes a session. The (logout) service would either have direct access to all application's server side sessions and destroy them directly, or it will have the ability to make a back-channel call to each application to tell the application that it must remove its session.

This technique can be quite effective as there is low-latency between when a user calls logout, and when they are then logged out of all applications. However it can add complexity and also additional development time for implementation. It will also require some way to ensure that new applications added to the system are added to this service.

Federated Logout

Federated User Logout may be something that you need to consider for your application. If you or your customers will be using a third-party IdP (i.e., something other than a Database Identity Provider) then the question of whether you need to log the user out of the IdP when they log out of your application is something you will need to answer. The answer depends on what your users would expect. If the application and/or IdP you use is tied closely to a customer organization and a central part of day-to-day operations, then it may be frustrating for users to get logged out of their IdP when they log out of your application. If not, then being logged out of the IdP may be expected, or in some cases even desired. In most B2B scenarios, our customers find that it is preferable not to perform federated logout for a user.

Project Planning Guide

We provide planning guidance in PDF format that you can download and refer to for details about our recommended strategies.

B2B IAM Project Planning Guide

Multiple Organization Architecture (Multitenancy)

Many B2B platforms implement some form of isolation and/or branding for their customers' organization, and this can add complexity to any Identity and Access Management (IAM) system. If this applies to you, then we recommend you take some time to read through our guidance and best practice advice concerning this type of environment.

Multiple Organization Architecture (Multitenancy) Overview

Keep reading