Verifying Logout Implementations

Knowledge Articles
1

Overview

This article details how to check on a logout implementation, which URLs should be seen in network logs, and what would appear in tenant logs.

Applies To

  • Logout

Solution

Tenant Logs to Check

  • Type: “slo” - A successful logout.
  • Type: “flo” - A failed logout.
  • If using the OIDC backchannel logout mechanism, there may be some additional log types seen:
    • Type: oidc_backchannel_logout_failed
    • Type: oidc_backchannel_logout_succeeded
  • A full list of log types can be found here.

Network Level

When checking network logs in the user’s browser, requests to the Auth0 tenant on one of the following URLs should be seen, depending on the implementation and the protocol in use:

  • If using the OIDC Logout endpoint:

    GET to https://{yourTenantDomain}/oidc/logout

  • Auth0’s alternative logout endpoint (this was the original logout endpoint before the introduction of the OIDC logout endpoint):

    GET to https://{yourTenantDomain}/v2/logout

  • If using the SAML protocol with Auth0 acting as SAML IdP, this could instead use:

    POST to https://{yourDomain}/samlp/CLIENT_ID/logout

Cookies

Following a logout, no change will be seen on cookies at the browser level, but the logout request will invalidate the Auth0 session cookies’ associated records on the tenant’s side, so the next time the user calls /authorize they should have to login again as the Auth0 session cookies will not be recognised, and new ones will be instead be set to track the login transaction.

Conversely, when a user has a valid session still with Auth0, i.e., a logout was not triggered/failed, and provided the user is still within the tenant’s configured session lifetime (session cookies have not expired), an /authorize request to the tenant should trigger Seamless SSO and not prompt the user to log in again, skipping the Universal Login page and redirecting the user back to the callback URL of the application: