eric wu

With over 7 years of experience in product marketing, I am passionate about creating and delivering impactful marketing strategies that drive customer value, business growth, and competitive differentiation. I have a strong background in launching new products, especially in Security, Generative AI and Cloud domains, where I have led several successful end-to-end product releases. I currently work as a Staff Product Marketing Manager at Okta, a leading identity and access management platform that empowers organizations to securely connect their people and technology.

Staff Product Marketing Manager, Auth0

Eric Wu

Auth0 for B2B Enhancements accelerates onboarding and streamlines identity management with self-service onboarding workflows, Group Provisioning with SCIM, Universal Logout, and more.

Identity That Helps You Sell: Introducing Auth0 for B2B Enhancements

Aaron Smalser

Aaron Smalser is a Principal Product Manager in Auth0.

Principal Product Manager

We’re thrilled to announce that Auth0 now supports Universal Logout integration with Okta Workforce Identity.

This integration, now generally available, enables organizations using Okta Workforce Identity as their Identity provider (IdP) to log users out of Auth0-powered applications whenever a logout or de-provisioning event occurs in Okta Workforce Identity. Auth0 customers can now leverage this feature in their Auth0-powered applications and significantly improve their customer organization's security.

## What Is Okta Universal Logout?

Universal Logout is a feature of[ Okta Identity Threat Protection (ITP)](https://www.okta.com/products/identity-threat-protection/), a capability of Okta Workforce Identity that leverages AI to detect and automate responses to identity threats. When ITP detects elevated risk for a given user, it can invoke Universal Logout to log the user out of the applications they are using.

<center> ![Identity Threat Protection](https://images.ctfassets.net/23aumh6u8s0i/46OUnojd394XtHUnigceUE/b55b089cd27a690551401a3ee4720f37/01_identity_threat_protection.png) </center>

Built on the[ Global Token Revocation](https://www.ietf.org/archive/id/draft-parecki-oauth-global-token-revocation-04.html) standard,  Universal Logout goes beyond the established OpenID Connect logout standards by revoking refresh tokens in addition to session cookies. This provides a comprehensive logout solution that spans across:

* Traditional web applications
* Browser-based JavaScript applications such as Single-Page Applications (SPAs)
* Native applications that use a mix of application sessions, identity provider sessions, and refresh tokens to keep the user authenticated 

Today, Okta Workforce Identity customers can use Identity Threat Protection and Universal Logout with popular SaaS apps like Google Workspace, Apple Business Manager, Microsoft Office 365, Salesforce, Slack, and Zoom. For other applications to work with it, developers would need to build a Global Token Revocation endpoint as described in[ Build Universal Logout for your app](https://developer.okta.com/docs/guides/oin-universal-logout-overview).

## Auth0 Now Supports Global Token Revocation Endpoints out-of-the-box

Auth0 customers federating with Okta Workforce Identity using the[ Okta](https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers/okta),[ SAML](https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers/saml), or[ OpenID Connect](https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers/oidc) connection types no longer need to build a global token revocation endpoint. Instead, with minimal configuration required, they can provide the Okta admin with Auth0’s connection-specific endpoint URL, as shown below:

![Global Token Revocation](https://images.ctfassets.net/23aumh6u8s0i/1MdMFDyxcudnb1krjigP6I/d2a462652b63008ee68378d3f4536c94/02_global_token_revocation.png)

When Auth0 receives a logout request, it validates it using the same key set used to validate Okta Workforce Identity-issued ID tokens and SAML assertions. It then terminates all[ Auth0 sessions](https://auth0.com/docs/manage-users/sessions/session-layers) for the user, revokes Auth0-issued[ refresh tokens](https://auth0.com/docs/secure/tokens/refresh-tokens), and if configured, triggers[ OpenID Connect back-channel logout](https://auth0.com/docs/authenticate/login/logout/back-channel-logout) to revoke application sessions, as the following diagram shows:

![Global Token Revocation Flow](https://images.ctfassets.net/23aumh6u8s0i/7Jjkjbk7CFTpRIuRQWB12Q/c928982863eb8f520a39ca3f63712096/03_diagram.png)

## Immediate Security Benefits for Apps Using Refresh Tokens and Auth0 Sessions

Auth0 supports various[ application architectures](https://auth0.com/docs/get-started/applications) via OpenID Connect and OAuth 2.0 identity standards and its[ quickstarts and SDKs](https://auth0.com/docs/quickstarts). This includes:

* **Traditional Web applications** that create their own[ application sessions](https://auth0.com/docs/manage-users/sessions/session-layers) and may use[ refresh tokens](https://auth0.com/docs/secure/tokens/refresh-tokens) and access tokens to access APIs through a secure backend. \

* **Browser-based JavaScript applications** that leverage the[ Auth0 session layer](https://auth0.com/docs/authenticate/login/configure-silent-authentication) or[ refresh tokens](https://auth0.com/docs/secure/tokens/refresh-tokens/refresh-token-rotation) to get access tokens to access APIs within a Web browser. \

* **Native or Mobile applications** that don’t run in a Web browser use refresh tokens and access tokens as the primary method of keeping users signed in.

Applications that use refresh tokens or leverage Auth0 sessions get these security benefits when the Universal Logout integration is enabled:

* For browser-based apps that[ leverage the Auth0 session](https://auth0.com/docs/authenticate/login/configure-silent-authentication), the user loses access the next time the application[ polls the Auth0 session](https://auth0.com/docs/authenticate/login/configure-silent-authentication#poll-with-checksession-), and Auth0 prompts the user to sign in again when redirected

* For apps that use refresh tokens, the user loses access as soon as their current access token expires, which can range from a few seconds up to the[ maximum access token lifetime](https://auth0.com/docs/secure/tokens/access-tokens/update-access-token-lifetime)** **configured in Auth0. 

Among applications that federate with Okta WIC today, a majority use either the Auth0 session layer or refresh tokens to get new tokens and keep users logged in.  

## Instantly Revoke Application Sessions Using OIDC Back-Channel Logout 

Web applications that create their own sessions can use Auth0’s existing[ OpenID Connect back-channel logout](https://auth0.com/docs/authenticate/login/logout/back-channel-logout/configure-back-channel-logout) feature to instantly terminate them when Auth0 receives a Universal Logout request.

To learn more, see the[ Auth0 SDKs](https://auth0.com/docs/authenticate/login/logout/back-channel-logout#auth0-sdks) and[ Implementation Examples.](https://auth0.com/docs/authenticate/login/logout/back-channel-logout#implementation-examples)

By integrating Universal Logout, developers using Auth0 can easily adopt the latest security standards for their B2B SaaS apps and offer them to their customers who use Okta Identity Threat Protection. 

Customers who use Okta Workforce Identity to grant their employees or partners access to Auth0-integrated applications can benefit from the improved security posture that Universal Logout provides. 

## Included in Your Auth0 Subscription at No Extra Cost

Support for Universal Logout is included in all Auth0 subscriptions that include the[ Okta](https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers/okta),[ SAML](https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers/saml), or[ OpenID Connect](https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers/oidc) connection types, including Enterprise, B2B Professional, B2B Essentials, and for all plans that include the Okta connection (B2C and Free).

What’s more, usage of the[ Okta Workforce Enterprise Connection](https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers/okta) does not count towards the[ Enterprise connection limit](https://auth0.com/docs/troubleshoot/customer-support/manage-subscriptions/monitor-subscription-usage#enterprise-connections). Customers are free to enable Universal Logout for as many Okta Workforce integrations as they need, subject to the other limits of their subscription.

## Learn More 

You can learn more about Okta Identity Threat Protection and Universal Logout Integration with Auth0 by reading our product documentation here:

* [Universal Logout Integration with Auth0](https://auth0.com/docs/authenticate/login/logout/universal-logout)
* [Okta Identity Threat Protection](https://help.okta.com/oie/en-us/content/topics/itp/overview.htm)

> Disclaimer: This article may contain hyperlinks to non-Okta websites that are created and maintained by third parties who are solely responsible for the content on such websites.


Okta Universal Logout Integration Now Supported in Auth0

joey devilla headshot 900px

I’m a Senior Developer Advocate at Auth0, and I like to work on various technologies. I’ve developed software for all sorts of platforms, from CD-ROM and the PalmPilot to my current area of focus, mobile phones, IoT devices, and AI. When I’m not looking for strange new platforms to write software for, I’m playing a strange old instrument — the accordion!

Senior Developer Advocate

Joey deVilla

peterfernandez_360

As an Architect, Consultant, and Engineer, I have more than 30 years of experience designing and developing secure and robust software solutions. When not helping teams deal with the complexities of Customer Identity, you can usually find me working behind the scenes, acting in or directing a show at my local theatre.

Principal Developer Advocate

Peter Fernandez

Learn how to add authentication (login and logout) to iOS apps built with SwiftUI with Auth0 and the Auth0.Swift package.

Get Started with iOS Authentication using SwiftUI, Part 1: Login and Logout

andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Andrea Chiarelli

Let’s take an overview of the new Session Management API, which allows you to manage your user sessions.

User session management allows developers to implement features ranging from controlling session concurrency to monitoring and terminating sessions. In this article, we will discuss the Session Management API, which allows you to manage user sessions in applications that integrate with Auth0.

## The Need for Managing User Sessions

When a user logs in to your application using Auth0, at least two sessions are initiated:

- The *Local Session* (*Application Session*). This session exists on your application's side. It typically uses cookies or similar mechanisms to store information like the user's login status, preferences, or any other data relevant to your application's functionality. Its primary role is to indicate to your application whether the user is currently logged in and authorized to access specific resources or features.
- The *Authorization Server Session* (*Auth0 Session*). This session is managed by Auth0's servers. It's typically stored in a cookie within the *auth0.com* domain or a custom domain associated with your Auth0 tenant. It's primarily used by Auth0 to facilitate features like Single Sign-On (SSO) and to determine if a user needs to re-authenticate when accessing other applications within the same Auth0 tenant.

> In case the user authenticates using a third-party Identity provider, such as Google, Facebook, GitHub, or others, you have a third session, the *3d party IdP session*, which tracks the interactions between the user and that Identity provider. See [this document](https://auth0.com/docs/manage-users/sessions/session-layers) for more info.

Your application's sessions are entirely in your hands, although Auth0 SDKs can help you with session creation. Auth0's session management is under Auth0's control. However, thanks to the new [Session Management API](https://auth0.com/docs/manage-users/sessions/manage-user-sessions-with-auth0-management-api), you can now manage Auth0 sessions from your application as well. The ability to manage authenticated user sessions in Auth0 can meet a few needs, such as:

- You can allow users to list their active sessions and close them by remotely logging out.
- You can allow an administrator to list all the user sessions and possibly force any of them to log out for security reasons.
- You can limit the number of concurrent user sessions.

Let's explore how you can use this new API.

## Set Up Access to the Session Management API

To use the Session Management API, you need the [Enterprise plan](https://auth0.com/pricing). If you don't have this plan but want to test the API, you can create a new tenant and get a free trial period.

You can use the Session Management API as you do with all the [Management API](https://auth0.com/docs/api/management/v2): basically, you need to enable your client application, [get an access token](https://auth0.com/docs/secure/tokens/access-tokens/management-api-access-tokens), and call the API endpoints.

### Enable your client

As a first step, you need to enable your client application to use the required scopes to use the Session Management API. In particular:

- The scope `read:sessions` enables your client to list sessions and get details about them.
- The scope `delete:sessions` allows your client to close a session, i.e., logging a user out.

To enable a client to these scopes, go to your [Auth0 dashboard](https://manage.auth0.com/) and select the application you want to enable. Make sure this is a [Machine to Machine application](https://auth0.com/docs/get-started/auth0-overview/create-applications/machine-to-machine-apps). Select the APIs tab on the application page and then toggle the *Authorized* switch button corresponding to the Auth0 Management API, as shown in the following picture:

![Auth0 Management API authorization](https://images.ctfassets.net/23aumh6u8s0i/2Lo0IwblYRUHaYSZumG0KV/5ba4a67cf84835252167fac11102c2c4/auth0-management-api-authorization.png)

Then, expand the Auth0 Management API section and filter the permissions list using the `session` keyword. You should get the `read:sessions` and `delete:sessions` items. Check them as shown in the following picture:

![Auth0 Management API session scopes](https://images.ctfassets.net/23aumh6u8s0i/6hTwgUYPtXviFLa5BlZtph/7167f08b695580ac2aac827a9e0a809f/auth0-management-api-session-scopes.png)

Don't forget to click the *Update* button to save your changes.

### Get an access token

Now, your application must request an access token to call the Management API. Depending on your specific scenario, you can get an access token in different ways. For example, in a test scenario you can [get it manually](https://auth0.com/docs/secure/tokens/access-tokens/management-api-access-tokens/get-management-api-access-tokens-for-testing#get-access-tokens-manually) from the Auth0 dashboard or you can use cURL, while in a production scenario, your application must request an access code programmatically.

For demonstration purposes, let's see how you can request an access token via cURL:

```bash
curl --request POST \
  --url https://YOUR_AUTH0_DOMAIN/oauth/token \
  --header 'content-type: application/json' \
  --data '{"client_id":"YOUR_CLIENT_ID","client_secret":"YOUR_CLIENT_SECRET","audience":"https://YOUR_AUTH0_DOMAIN/api/v2/","grant_type":"client_credentials"}'
```

Replace the placeholders `YOUR_AUTH0_DOMAIN`, `YOUR_CLIENT_ID`, and `YOUR_CLIENT_SECRET` with the respective values from your client configuration.

This request generates a response as the following:

```bash
{ "access_token":"eyJhbGci...",
  "scope":"read:sessions delete:sessions",
  "expires_in":86400,
  "token_type":"Bearer"
}
```

You will use the value of the `access_token` property to demonstrate that you are authorized to call the Management API.

### Call the API

Now that you have the access token, you can call the API endpoints by passing it in the `Authorization` header, as shown in the following cURL request:

```bash
curl --request GET \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/AUTH0_API_ENDPOINT' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN' \
  --header 'content-type: application/json'
```

Replace the placeholders `YOUR_AUTH0_DOMAIN`, `YOUR_ACCESS_TOKEN`, and `AUTH0_API_ENDPOINT` with the respective values.

## Managing the User Sessions

Once we have enabled the client and obtained the access token, let's see how to actually use the Session Management API.

Let's start by listing the active sessions of a specific user. You can use the `/api/v2/users/{userId}/sessions` endpoint as shown in the following example:

```bash
curl --request GET \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/users/auth0%7C8374f7459j7493u84335/sessions' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

In this example, you send a GET request to the endpoint by specifying your Auth0 domain, the user ID, and the access token. As a response, you will get a JSON object like the following:

```bash
{
  "sessions": [{
    "id": "2Lw8dT76wJpOl924",
    "user_id": "auth0|8374f7459j7493u84335",
    "created_at": "2024-05-10T12:04:22.3452",
    "updated_at": "2024-05-10T12:04:22.3452",
    "authenticated_at": "2024-05-21T11:29:12.4251",
    "authentication": { "methods":[
      {
        "name": "pwd",
        "timestamp": "2024-05-21T11:29:12.4251"
      }
    ]},
    "idle_expires_at": "2024-05-21T12:29:12.4251",
    "expires_at": "2024-05-21T18:29:12.4251",
    "device": {
      "initial_ip": "142.250.184.206",
      "last_ip": "142.250.184.206",
      "user_agent": "Mozilla/5.0...",
      "initial_asn": "8612",
      "last_asn": "8612"
    },
    "clients":[ {"client_id": "Hwo482a51heU632d34"} ]
    }
  ]
}
```

This is an object with the `sessions` array that lists the user's active sessions. Each session is represented by an object with some properties: the session ID (`id`), the user ID (`user_id`), the time stamp of their authentication (`authenticated_at`), the authentication method (`authentication`), the device on which the session is active (`device`), the application client used by the user (`clients`), etc.

In the example above, only one session is returned for that user.

If you have a session ID, you can access the data about that session by using the `/api/v2/sessions/{id}` endpoint. You can get a session ID from the `sid` claim of the ID or [Logout token](https://auth0.com/docs/authenticate/login/logout/back-channel-logout#tokens-in-oidc-back-channel-logout-communications). The following example shows how to get the session details given its ID:

```bash
curl --request GET \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/sessions/2Lw8dT76wJpOl924' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

You will receive a JSON object representing that single session, as shown in the following:

```bash
{
  "id": "2Lw8dT76wJpOl924",
  "user_id": "auth0|8374f7459j7493u84335",
  "created_at": "2024-05-10T12:04:22.3452",
  "updated_at": "2024-05-10T12:04:22.3452",
  "authenticated_at": "2024-05-21T11:29:12.4251",
  "authentication": { "methods":[
    {
      "name": "pwd",
      "timestamp": "2024-05-21T11:29:12.4251"
    }
  ]},
  "idle_expires_at": "2024-05-21T12:29:12.4251",
  "expires_at": "2024-05-21T18:29:12.4251",
  "device": {
    "initial_ip": "142.250.184.206",
    "last_ip": "142.250.184.206",
    "user_agent": "Mozilla/5.0...",
    "initial_asn": "8612",
    "last_asn": "8612"
  },
  "clients":[ {"client_id": "Hwo482a51heU632d34"} ]
}
```

## Forcing Session Termination

In addition to getting information about the user sessions, you can also terminate them if your application has the `delete:sessions` scope enabled. You can call both endpoints `/api/v2/users/{userId}/sessions` and  `/api/v2/sessions/{id}` using the `DELETE` method. For example, the following cURL command terminates a specific user session:

```bash
curl --request DELETE \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/sessions/2Lw8dT76wJpOl924' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

The following command deletes all the sessions of a specific user:

```bash
curl --request DELETE \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/users/auth0%7C8374f7459j7493u84335/sessions' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

Session termination does not automatically log a user out of the application. As mentioned earlier, multiple sessions are involved in an application, and logout must be handled properly. Read [this article to get an idea of logout complexity](https://auth0.com/blog/the-not-so-easy-art-of-logging-out/).

In particular, session termination events are connected to the [OpenID Connect Back-Channel Logout](https://auth0.com/docs/authenticate/login/logout/back-channel-logout) mechanism. Therefore, to trigger application logout through the Session Management API, your application must be configured to use the `session-revoked` initiator. Read [this document](https://auth0.com/docs/authenticate/login/logout/back-channel-logout/oidc-back-channel-logout-initiators#configure-oidc-back-channel-logout-initiators) to learn how to configure your application to use the `session-revoked` initiator.

## Sessions and Refresh Tokens

Session termination forces the user logout. However, if an application requests a refresh token at login time, this refresh token is still available to the application even after the user session terminates.

This may be an intended or unintended situation, depending on the application's specific requirements. For example, consider an application that needs to call an API on a scheduled basis. It needs a refresh token to ensure an access token even if the user does not have an active session. On the other hand, your application can use a refresh token only to renew an access token with a limited lifetime, but you do not want the refresh token to survive the user session.

In the first case, terminating a user session will work as shown so far. You don't need to take an extra step to revoke the refresh token.

In the second case, the session termination is not enough. You also need a way to invalidate the current refresh token. For this purpose, you can use a few endpoints to help you manage refresh tokens.

> To enable your client application to manage refresh tokens, you have to add the `read:refresh_tokens` and `delete:refresh_tokens` scopes to the Management API configuration in the Auth0 dashboard.

The following command shows how to list all the refresh tokens associated with a given user:

```bash
curl --request GET \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/users/auth0%7C8374f7459j7493u84335/refresh-tokens' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

You get a JSON object containing the list of the refresh tokens with all the details, as in the following example:

```bash
{
  "refresh_tokens": [{
    "id": "6srfsU4dh510",
    "user_id": "auth0|8374f7459j7493u84335",
    "client_id": "Hwo482a51heU632d34",
    "created_at": "2024-05-10T12:04:22.3452",
    "updated_at": "2024-05-10T12:04:22.3452",
    "idle_expires_at": "2024-05-21T12:29:12.4251",
    "expires_at": "2024-06-21T18:29:12.4251",
    "session_id": "2Lw8dT76wJpOl924",
    "rotating": true,
    "resource_servers": [{ audience: "http://myapi.com", scopes:"read:users"}] 
  }]
}
```

To delete this specific refresh token, you can call the `/api/v2/refresh-tokens/{tokenId}` endpoint as in the following example:

```bash
curl --request DELETE \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/refresh-tokens/6srfsU4dh510' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

Notice how you specify the ID of the refresh token to delete.

If you want to delete all the refresh tokens associated to a user, you can use the following command:

```bash
curl --request DELETE \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/users/auth0%7C8374f7459j7493u84335/refresh-tokens' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

> Consider that refresh token revocation through the `DELETE` command on the endpoints shown above runs asynchronously. This means that refresh tokens are not immediately revoked when the command finishes running.

## Summary

This article has given you an overview of Auth0's Session Management API with some examples of endpoint invocation via cURL. We started with activating the client application and getting the access token, then moved on to getting a user's session list and terminating a specific session.

You then learned about the relationship between sessions and refresh tokens and how to revoke refresh tokens associated with a user.

Now that you have a basic understanding of how to use the Session Management API, you can build a better security experience for your users.


Introducing the Auth0 Session Management API

Explore the logout issues with Blazor Server applications and learn how to resolve them.

Blazor Server and the Logout Problem

Logging out of an application may not be as easy as it can seem at first. Let's explore the options available in the different scenarios.

We put a lot of emphasis on the login step of an application: authentication methods, authentication factors, user identity protection, passwordless, single sign-on, etc. What about the logout step? Do you think it's so easy to implement that it doesn't deserve much attention?

Implementing logout may not be as easy as you think at first, especially in contexts where multiple actors may be involved in the login step, as it may happen in the Auth0 context.

This article will give you a high-level overview of logout issues and the different types of logouts. It will not go into the implementation details of logout, but you will get an idea of the complexity behind this apparently simple operation.

## A Few Questions about Logout

An Arabic proverb reads: "*Think of the going out before you enter*". This highlights the importance of planning well for a way out before entering any environment, physical or virtual. This also applies to logging out of applications. Understanding how to properly log out of an application has the same weight as logging in.

Before you dive into the different types of logout, ask yourself a few questions that may help you understand how to implement it for your application needs.

### What is the relationship between login and logout?

Login is the initial step in an authenticated session, which is a session that has an authenticated user associated with it. Logout is the final step of an authenticated session, that is, the last step in a session whose activities are bound to an authenticated user. Before the login and after the logout, any user activity in your application is not bound to an authenticated user but to a so-called unknown user, often called an *anonymous user*.

So, we can say that during the time between the login and the logout steps, your application knows who the logged-in user is.

### How many authenticated sessions do you have?

In the Auth0 context, when your application user logs in by using the [Universal Login page](https://auth0.com/docs/authenticate/login/auth0-universal-login), Auth0 creates a new authenticated session. Likewise, when your application receives confirmation of user authentication from Auth0, it should create another new authenticated session.

The first session tracks the interaction between the user and the Auth0 server: let's call it the *Auth0 session*. The second session tracks the interaction between the user and your application: let's call it the *Application session*. The following diagram highlights these two sessions in the context of Auth0:

![Application session and Auth0 session](https://images.ctfassets.net/23aumh6u8s0i/7GL9lhge2VPiguMql1fZba/be9b5db48db07160a24ea887471051ab/application-auth0-sessions.png)

You can use a third-party Identity provider (IdP) to authenticate your users through Auth0. For example, you can allow your users to authenticate with their favorite social media providers, such as Google, Facebook, or Twitter. In this case, a third session is created in addition to the Auth0 session and the application session: the 3rd-party IdP session. The following diagram illustrates this new scenario:

![Application session, Auth0 session, and 3d party IdP session](https://images.ctfassets.net/23aumh6u8s0i/4YiylvkgLKQSeoXJu1xKIh/9f51fc289d1b1f9f9d74eb815006d421/application-auth0-3d-party-idp-sessions.png)

### Why do you need to log out?

This may seem like a strange question, but think a bit about it. What is the purpose of logging out of an application? Basically, it means terminating an authenticated session. All the information associated with the session must be destroyed so that unauthorized parties can't take it over. In other words, it's a security measure. But you should not underestimate that it also has an impact on the user experience, as you will see later.

### Where do you want to log out from?

Again, this may seem like a silly question at first. Probably the most natural answer is: "*I want to log out of the application*". But as you learned earlier, there are scenarios where there are multiple authenticated sessions. Which of these sessions do you need to close? Just the application session? All sessions?

You will learn about the options in a moment.

### Why do you ask these questions?

These questions (some of which are not yet answered) should help you think about the correct way to let your users log out of your application in your specific scenario. Carefully analyze the context of your application to find the right way to let your users log out. With these questions in mind, let's see what types of logouts are available.

## Types of Logouts

I guess that it shouldn't sound weird at this point to talk about different types of logouts. Just as there are different ways to log in to your application, there are different ways to log out. Let's explore them.

### Application logout

Logging out of your application means closing your application session. How you close your application session depends on how it is implemented. For example, if your application is a [regular web application](https://auth0.com/docs/get-started/applications), you might have implemented your session using a cookie and session storage on the server side. To close the user's session, your application should invalidate the cookie and clear the session storage. Handling your application session is your responsibility.

Closing your application session doesn't close the Auth0 session. This means that the user's session with Auth0 is still alive. Technically, this means that the user's browser still has a valid authentication cookie issued by Auth0. If the user accesses the Universal Login page to authenticate while the Auth0 session is still valid, they are not even prompted for their credentials. Their authentication status is confirmed, and a new ID token is issued.

The following diagram shows the session status after application logout:

![Application logout](https://images.ctfassets.net/23aumh6u8s0i/4l8XzMQc9fJn9nKfPhhWm2/43654bd6f3da2616d3241c0f0b66caec/application-logout.png)

It is up to you to decide whether this logout type is right for your application. You know your application business scenario and the user experience you want to provide to your users.

### Auth0 logout

Suppose you don't want your user to be left with an active Auth0 session when they log out of your application. In this case, you must close both your application session and the Auth0 session.

As mentioned before, it is your responsibility to handle the logout of your application. To close the user's Auth0 session, your application must call the [Auth0 logout endpoint](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-auth0). This way, the next time the user accesses the Universal Login page, they will be prompted for their credentials.

In short, when the user clicks the logout button in your application, you close your application session and then call the Auth0 logout endpoint.

> Currently, Auth0 supports two logout endpoints: the [OIDC logout endpoint](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-auth0) and the [alternative logout endpoint](https://auth0.com/docs/api/authentication#logout).

The following diagram shows the session status after application and Auth0 logouts:

![Application and Auth0 logout](https://images.ctfassets.net/23aumh6u8s0i/2jGrD0v3xLCldzzMYX9gjb/9870f5bab211f2f47beac09a2b05b356/application-auth0-logout.png)

Check if this logout type is appropriate for your needs.

### Federated logout

Suppose that your application allows users to log in with a third-party Identity provider, such as Google, via Auth0. As you've already seen, in this scenario, you have the sessions shown in the following diagram:

![Application session, Auth0 session, and 3d party IdP session](https://images.ctfassets.net/23aumh6u8s0i/4YiylvkgLKQSeoXJu1xKIh/9f51fc289d1b1f9f9d74eb815006d421/application-auth0-3d-party-idp-sessions.png)

If you apply the application and Auth0 logout, the IdP session remains active.

This may be an acceptable scenario in some contexts. For example, most users use [social logins](https://marketplace.auth0.com/features/social-connections) to access multiple independent applications. If they use Google to access your application, there is a high probability that they are already authenticated with Google because they may have Gmail or some other open application that requires Google as the IdP. So, when your user logs out of your application by closing only the application session and the Auth0 session, they can still use Gmail or any other application they have logged in to through Google.

However, there are scenarios where this approach may not be appropriate. Consider the case where the third-party IdP is not a social media provider but an [enterprise IdP](https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers). In these scenarios, you may want the user to log out of the IdP when they log out of your application. The [Federated logout](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-idps) accomplishes this goal. After logging out of the application, the authenticated sessions involved in your scenario will look like this:

![Federated logout](https://images.ctfassets.net/23aumh6u8s0i/13qgFDDmMVx2bjhQX7x4wb/2f948733cc09c9d9c9eb3c948af26b31/federated-logout.png)

> Note that not all third-party IdPs support Federated logout. Check [which ones](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-idps#federated-logout-support) support it.

The Federated logout introduces some user experience challenges. While logging out of your application and Auth0 is expected by the user, logging out of a third-party IdP may be something unexpected and even annoying to the user. Consider a user who uses Google to access your application, and after they log out of your application, they are unable to access their email on Gmail because their authenticated session has been terminated. As a best practice, you should make your users aware that they are logging out of their third-party IdP. For example, you can require confirmation to log out of the third-party IdP. Alternatively, you can implement the logout function so that the user can choose whether or not to log out of their third-party IdP as well.

### Global logout

The logout scenarios analyzed so far assume that there is a single application and that the user logs out of that application. What happens when multiple applications are involved in the same authenticated session? What if the user logs out of the third-party IdP instead of your application? What is the desired behavior?

The following diagram illustrates this specific scenario:

![multiple-application-auth0-3d-party-idp-sessions](https://images.ctfassets.net/23aumh6u8s0i/6ndpGiqaF3WYTo1iPCSpep/687586187b40b966e293e676fb08c423/multiple-application-auth0-3d-party-idp-sessions.png)

The diagram shows a situation where two applications (Application A and Application B) share the same authenticated sessions: the Auth0 session and a third-party IdP session.

> This scenario would be similar even without the third-party IdP. However, the inclusion of the third-party IdP makes explicit the case where the user logs out of it instead of one of the applications.

As said before, what to do when the user logs out of one of these applications or from the IdP depends on your business needs. In some scenarios, you may want to do nothing: the other applications will continue to work until the user logs out of them. In other scenarios, you may want to terminate the sessions of the other applications.

The logout that terminates the sessions of the other applications is usually called **Global logout** or **Distributed logout**. From a certain point of view, it can be seen as the counterpart of the [Single Sign-On (SSO)](https://auth0.com/docs/authenticate/single-sign-on). For this reason, it is also known as **Single Logout (SLO)**, especially in the [context of SAML](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-saml-idps).

Basically, when a user logs out of one of the applications sharing the same authenticated session, a logout request is sent to the other applications. The details of how this happens depend on the specific protocol (e.g., SAML, OIDC), where the initial logout happens (one of the applications or the IdP), and the type of application (regular web application, SPA). This article will not go into those details. If you are curious, take a look at these docs:

- [OpenID Connect Session Management](https://openid.net/specs/openid-connect-session-1_0.html). The OIDC specification for implementing Global logout by actively monitoring the user's current authentication status.
- [Front-Channel Logout](http://openid.net/specs/openid-connect-frontchannel-1_0.html). The OIDC specification for implementing Global logout when the browser notifies the IdP of the application session termination.

- [Back-Channel Logout](https://auth0.com/docs/authenticate/login/logout/back-channel-logout). A high-level overview of the [OpenID Connect Back-Channel Logout](https://openid.net/specs/openid-connect-backchannel-1_0.html) specification, i.e., when a regular web application communicates the termination of the application session to the IdP.

- [Best Practices for Application Session Management](https://auth0.com/blog/application-session-management-best-practices/). A blog post about the best practices for checking and terminating authenticated sessions.

Of course, the same user experience issues we mentioned for the Federated logout also apply to Global logout.

## Life after Logout

You have explored the different types of logouts you may encounter as you deal with increasingly complex scenarios. But what happens after the user logs out of your application? Since their authenticated session terminates, they are no longer authorized to access the protected pages of your application. Where will they be redirected?

This is mostly a user experience decision. You can redirect your users to the home page of your application, a specific page, or the authentication page (i.e., the Universal Login page). The choice is up to you, but there are a few points to keep in mind:

- When your logout involves Auth0 (i.e., it's not just an Application logout), you'll need to specify where to redirect the user. Learn how to do this based on the [OIDC logout endpoint](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-auth0#redirect-users-after-logout) or the [alternative logout endpoint](https://auth0.com/docs/authenticate/login/logout/redirect-users-after-logout).
- Register the URL of the page to which users will be redirected in the *Allowed Logout URLs* field of your Auth0 Application Settings in the Auth0 dashboard. This is a security measure to prevent URL injection attacks.
- Let's say you only use the Application logout or allow users to authenticate with a third-party IdP, but you don't use the Federated logout. In these cases, be sure to redirect users to an unprotected page after they log out. Otherwise, their active authenticated session with Auth0 or the IdP will re-authenticate them, and a new application session will start. The perceived effect is that the users will not log out of your application.

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

## Summary

In this article, you were invited to ask yourself a few questions about when you are going to implement your logout function. These questions should help you choose the right approach to define the logout for your specific scenario.

Then you explored some logout types based on different scenarios: you started with a scenario where the simple Application logout might be enough and arrived at a scenario where multiple applications are involved, and you need a Global logout.

At the end of this article, I hope you now have an idea of the complexity behind the logout step. It may look easy at first, but in scenarios where multiple applications and multiple IdPs are involved, it becomes very challenging. The alternative to this complexity would be to [discourage your users from logging out of your application](https://www.theverge.com/23670169/logout-button-ui-websites-design-ui-interface). Is that what you want? 🙂

The Not-So-Easy Art of Logging Out

Sumana Malkapuram

Expert in Identity and Access Management. Excellent skills in various IAM products and Open standard protocols.
I enjoy solving complex problems and providing quality solutions in enterprise security.

Specialties: Identity and Access Management, Python, Java, Javascript

Staff Solutions Architect

Let's see how to maintain application sessions in different scenarios

Best Practices for Application Session Management

37590801?s=460&v=4

A software engineer who dreams about non-electric sheep and autonomous vehicles and likes to champion security.

Software Engineer

Dan Arias

Learn how to add login, logout, and sign-up to Vue.js using a plugin, how to create vue-router guards, and how to make secure API calls from a Vue.js app.

The Complete Guide to Vue.js User Authentication with Auth0

Learn how to implement login, logout, and user profiles in Android apps using Kotlin and Auth0.

"logout"