Verifying Logout Implementation using Details in Network and Tenant Logs

Overview

This article clarifies how to verify a logout implementation by detailing the expected log entries in the tenant and the network calls observed in the browser.

Applies To
  • Logout
Solution

The following artifacts appear when verifying a logout implementation:

  • Tenant Log Entries The tenant log shows the following log types for logout events:

    • Type: "slo": Indicates a successful Single Logout (SLO).

    • Type: "flo": Indicates a failed logout. If the implementation uses the OpenID Connect (OIDC) backchannel logout mechanism, the following additional log types appear:

    • Type: "oidc_backchannel_logout_failed"

    • Type: "oidc_backchannel_logout_succeeded"
      Refer to the Log Type Codes for a complete list. 

 

Network Level Observe network logs in the user's browser for requests to the Auth0 tenant on one of the following URLs, depending on the implementation and protocol in use:

  • OpenID Connect (OIDC) Logout Endpoint: The client sends a GET request to the following endpoint:

https://<yourTenantDomain>/oidc/logout

Consult documentation on Log Users Out of Auth0 with OIDC Endpoint. 

 

  • Auth0's Alternative Logout Endpoint: The client sends a GET request to the following endpoint:

https://<yourTenantDomain>/v2/logout

Consult documentation on Auth0 Logout - GET /v2/logout.

 

  • Security Assertion Markup Language (SAML) Protocol: (Auth0 acts as the SAML Identity Provider (IdP)) The client sends a POST request to the following endpoint:

https://<yourDomain>/samlp/CLIENT_ID/logout

Consult documentation on SAML Logout.

 

  • Cookies
    No change appears in browser-level cookies following a logout. However, the logout request invalidates the Auth0 session cookies' associated records on the tenant's side.

    • The next time the user calls /authorize, the user must log in again because the Auth0 session cookies are not recognized, and new cookies are set to track the login transaction.

    • Conversely, if the user still has a valid session (that is, logout was not triggered or failed) and is within the tenant's configured session lifetime (session cookies have not expired), an /authorize request to the tenant triggers Seamless Single Sign-On (SSO) and does not prompt the user to log in again. This action skips the Universal Login page and redirects the user back to the application's callback URL.

Related References

Recommended content

No recommended content found...