Logout (B2B)

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.

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.

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.

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 allowlisted in the Dashboard to mitigate open-redirect security vulnerabilities. You can allowlist them at the tenant or application levels.

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.

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.

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.

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 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.

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