Terminating an authenticated session when it’s no longer needed, otherwise known as Logout, is a good practice when it comes to security hygiene. Providing logout capability helps mitigate a number of potential security issues, including the likelihood that unauthorized parties can “take over” a session. In our architecture scenarios, we provide general purpose guidance on B2B Logout, which we recommend reviewing alongside the guidance provided here. For this scenario, Logout is almost identical to logout in any other system, so it will have the same level of complexity as described in our standard documentation.

​
Database Connection

Using our Hoekstra & Associates example, the following diagram illustrates the flow typically encountered when dealing with a user authenticated via an Auth0 Database Connection. Let’s walk through this flow to see what occurs; note that most of the workflow described will typically be handled by using the relevant Auth0 SDK or library associated with your technology stack:
Architecture Scenarios - MOA - Isolated Users, Shared Apps, Logout Flow
  1. Jennifer clicks logout.
  2. Hoekstra & Associates’ Instance of Travel0 Corporate Booking redirects the browser to the Travel0 Auth0 Tenant at https://auth.travel0.net with the following parameters:
    1. returnTo: https://hoekstra.corp.travel0.net/logoutComplete
    2. client_id: Client ID associated with the Application created in the Travel0 Auth0 Tenant for the Hoekstra & Associates instance of Travel0 Corporate Booking.
      Best PracticeDefine Applications independently in Auth0 to make it easier to configure the returnTo URL where the corresponding client_id is used to provide correct validation of the supplied URL. To learn more, see Provisioning.
  3. The Travel0 Auth0 Tenant terminates the Auth0 session established on behalf of the user, removing any SSO information, and redirects the browser to the specified returnTo URL.
  4. The Hoekstra & Associates Instance of Travel0 Corporate Booking renders a page to let Jennifer know that she successfully logged out, likely with a button to log back in if desired.
    1. At this stage, the Travel0 Corporate Booking instance will typically want to clean up the application session associated with the user, too.
If you do not wish to remove the user’s SSO session with Auth0, then the application can simply terminate the application session without redirecting to the /logout endpoint on the Auth0 Tenant. While the user will be logged out of the application, they will still have an SSO session with Auth0. In this case, you will likely want to tell the user that they are still logged in to the Auth0 Tenant, and that if they click login again, they may not be challenged to enter first-factor credentials.

​
Enterprise Connection

For this scenario, implementing Logout can be a little more complex than it is when using a Database Connection. You still have the option to either logout from only the application or to have logout from the application result in logout from the Auth0 Tenant, too. However, you may also have the option of allowing logout from the organization’s (IdP), which most applications avoid, especially if users have access to other corporate applications to which they may need to stay logged in. Avoiding this, however, may result in users who subsequently click the login button being authenticated automatically without interactively providing first-factor credentials. Such functionality may make for an unexpected user experience, so you should consider communicating this to the user. Using our MetaHexa Bank example, let’s see how this Logout implementation might flow with a user authenticated via an Enterprise Connection to MetaHexa Bank; again, most of the workflow described will typically be handled by using the relevant Auth0 SDK or library associated with your technology stack:
Architecture Scenarios - MOA - Isolated Users, Shared Apps, Enterprise Logout Flow
  1. Amintha clicks logout.
  2. MetaHexa Bank’s Instance of Travel0 Corporate Booking redirects the browser to the Travel0 Auth0 Tenant at https://auth.travel0.net with the following parameters:
    1. returnTo: https://metahexa.corp.travel0.net/logoutComplete
    2. client_id: Client ID associated with the Application created in the Travel0 Auth0 Tenant for the MetaHexa Bank instance of Travel0 Corporate Booking.
    3. federated:  Optional parameter used to log the user out of the MetaHexa Bank IdP. When specified, the browser is redirected to the /logout endpoint associated with the MetaHexa Bank IdP, which terminates the user’s session before redirecting the browser back to the Travel0 Auth0 Tenant.
      Best PracticeDefine Applications independently in Auth0 to make it easier to configure the returnTo URL where the corresponding client_id is used to provide correct validation of the supplied URL. To learn more, see Provisioning.
Steps 3 and 4 will match those described in the Database Connection scenario, but will use Amintha in place of Jennifer and MetaHexa Bank (metahexa.corp.travel0.net) in place of Hoekstra & Associates.

​
Social Connection

In the context of Social Connections, Logout follows a similar pattern to that associated with an Enterprise Connection, but the upstream IdP is associated with the social provider rather than any specific organization. You will almost certainly never want to leverage federated logout capability with a social provider because the resulting user experience would be too disruptive.