We have to give our users the option to sign out of our application. This would require them to log back in for further use. However, it appears the auth0 session cookie is not deleted for some reason when implementing the https://YOUR_AUTH0_DOMAIN/v2/logout?returnTo=http%3A%2F%2Fwww.example.com.
Even though the redirect works, the user is automatically logged back in after calling webAuth.authorize(); while you would expect to be asked to re-enter your credentials.
Calling this function for the first time, the user is required to enter username and password. However, they are never required again until the token expires.
Unfortunately, even the examples provided (via download section) do not address this. Any help/guidance is greatly appreciated. Thank you,
1 Like
Problem is that the logout (session cookie delete) in combination with the re-login happened too fast. Putting a delay on calling webAuth.authorize() showed that the user is successfully logged out. You certainly don’t want to put a delay on this function. In my case I am now forwarding to a “Logged out” page that also offers the option to log back in.
@jbrenna depending on the example you are referring to, I believe the example may only be clearing localStorage upon logout, leaving the Auth0 session remaining and this may be why when we call webAuth.authorize() again we log in automatically and are not asked to re-enter our credentials. However, I believe calling that v2 logout endpoint should remove the Auth0 session (in auth0.js that would be calling the webAuth.logout() which redirects to the v2 logout endpoint) let me do some investigating.
1 Like
@jbrenna were you able to solve your webAuth.authorize() logout issue? Can you let me know what example you are/were using?
I have the same problem, the cookie is not deleted on logout and I can’t log in with a different user. Could you show me where I can find some docs related to this ?
Best
@alexandre1 the overarching docs on logout can be found here:
Let me know if this helps!
1 Like
thanks it worked.
there is nothing about this in the vuejs documentation (which is overall very confusing).
glad to hear it worked!
Which Vue.js documentation were you looking at? This is great feedback! We are always looking to improve our documentation. I can pass that information along to the correct team.
this article The Complete Guide to Vue.js User Authentication with Auth0
and all I could find on the website.
There are two libraries which are looking similar aut0-js and auth0-lock…
I nice complete example with user profile, admin roles etc would be awesome.
Best
1 Like
@kimcodes I seem to be having a similar issue except it is occurring with the checkSession() method to see if the user is logged in.
Is it true what @mario.eisold said about needing a delay?
With our web app the logout redirects back to the auth handling page which straight away issues a checkSession() call to see if the user is logged in and we are finding that a lot of the time we are stuck in a loop where no matter how many times we log out (with a call to /v2/logout endpoint) we are never truly logged out (I have checked the Auth0 logs and they say that the logout was successful).
One thing I have noticed is that the /v2/logout endpoint does not clear any cookies (no set-cookie headers are returned) and then when the checkSession() occurs it sends the old cookie.
Any clarification of how these processes are supposed to work would be much appreciated!
This is not working. Even though i call the /v2/logout endpoint, i am still being logged in directly when calling the webAuth.authorize() function. The logs in my Auth0 dashboard claims the logout to be successful though.
This is happening using Ionic v3.
we have Nico who provided some further information on the logout functionality that may be useful/helpful for specific cases, found here: Auth0 SLO where Auth0 acts both IDP and SP - #7 by nicolas_sabena
I am copying over the post from the above thread:
I can confirm that, as of now, Auth0 will not reach out to the upstream identity provider (a “federated” logout) if the original logout request was a SAML logout request (i.e. it came from a SAML service provider).
Auth0 will issue a logout request to the upstream IdP if the strategy supports it (that’s what the logout URL is for in SAML connections) when you use the /v2/logout endpoint with the ?federated option (see Logout). This endpoint is meant to be used by OAuth2/OIDC clients mostly. You can’t use it from a SAML relying party, though, because it does not do the SAML SLO (does not send a SAML logout request to all other participant service providers).
So, to sum up, regardless of the protocol used in the upstream connection,:
- SAML logout requests from SPs will not cause a logout request to the upstream connection.
- WS-Federation logout requests will cause a logout request to the upstream connection (if supported).
/v2/logout will cause a logout request to the upstream connection (when supported) if the federated parameter is used.
I do agree that the above behavior is somewhat inconsistent and could be improved. If this is something you need, I would encourage you to leave feedback at https://auth0.com/docs/feedback, as customers requests will help the Product team prioritize features.
Please let me know if this helps clarify things. If not, simply let me know and I can have someone jump in to help clarify any processes further on how they are intended to behave!
Hi @kimcodes
Thanks for the information!
Unfortunately that talks about logging out of the upstream IDP while this issue is with logging out of Auth0 without regard for the upstream IDP.
The expected functionality is that if you log out of Auth0 using the /v2/logout endpoint, you should be presented with a login screen by Auth0 (and authorize() / checkSession() should fail with login required).
1 Like
Hi @charsleysa.
Just to be clear, there should be no need for a delay after the logout, assuming everything is working properly.
When you redirect the user to the /v2/logout endpoint, Auth0 will clear the session server-side and redirect to the returnTo URL.
If a checkSession or /authorize gives back a token without a user prompt, it would be very interesting if you can provide a .HAR file showing this situation for further analysis.
Hi @nicolas_sabena
I’ve attached a .HAR file showing this situation.
In the file you’ll see a logout request being performed with a 302 HTTP result redirecting back to our web app which then makes a request using checkSession() which succeeds. (This is also reflected in the Auth0 logs with a Logout Success entry followed by a Silent Auth Success entry).
logout_process.har (8.8 MB)
Thanks @charsleysa. The issue is mostly clearly seen on the .HAR file. The actual response from the /authorize request in checkSession request is not shown, but I see it immediately does a request to the /userinfo endpoint, so I’m assuming that the server returned a token.
Can you share the snippet of code where checkSesion is used (and the callback provided)?
I’ll be trying to reproduce this on my side.
Hi again @charsleysa. I tried to reproduce on my side, no luck so far. I even tried logging in to the application mentioned in the .HAR file.
I see, in the .HAR file, that the checkSession request happens a couple of minutes after the logout. How do you trigger that in your application? Can you give me instructions on how to reproduce, with your published application, on my side?
Hi @nicolas_sabena
Instructions to reproduce the issue are as follows:
- login to dashboard at https://web.staging.mymahi.co.nz
- logout of the dashboard by clicking on your name in the top right corner
- you’ll see the page reload and be taken straight back into the dashboard without being asked to login again
I have found that it doesn’t occur 100% of the time, but from basic testing I would say that it occurs at least 80% of the time.
In the mean time I’ll try to isolate the authentication code to create a reproducible demo.
I just tried your app. Couldn’t reproduce yet, but notice some unusual behavior: when navigating to the app’s logout endpoint, https://web.staging.mymahi.co.nz/auth/logout, does a checkSession request (probably as a consequence of the authenticated getter, but you’ll have to debug this more closely). Without awaiting this checkSession request to finish, the logout is requested. On the backend, this is seen as two independent requests for the same session processed at the same time. The logout probably ends first, and the /authorize from the checkSession call ends after that and ends up leaving a valid session for the user after all.
So, in a nutshell, avoid doing the checkSession right before the logout redirect or, if you need to do it, await for the promise to finish before redirecting to the logout.
Hope that makes sense!
1 Like
Hi @nicolas_sabena
First of all I would like to say a big thank you for helping solve my issue.
With the feedback you provided we found a bug in our code that caused checkSession to be initiated during the logout procedure.
The problem is a race condition caused by two simultaneous calls to Auth0, one to the /authorize endpoint and one to the /v2/logout endpoint.
I have been able to recreate the issue with a couple of simple modifications to the Auth0 Angular sample (specifically I have modified the login and logout functions in the auth service).
Here’s the repo. What you should experience is the following:
- first login after you click the login button you are prompted to login using the Auth0 Universal Login
- when you click logout you are redirected to the Auth0 logout endpoint and immediately redirected back to the app
- when you click login again, you’ll notice that you are not prompted with a login screen (and in the network tab you’ll see a succeeded call to
/authorize done by the checkSession call in the login function)
The modified sample does not store the result of the checkSession race condition, only output to console (as seen in the code).
Now this is where my expertise is limited but in my opinion a race condition shouldn’t cause a session to still be valid. Is this something Auth0 considers a bug in their system or is this considered to be a possible implementation flaw by developers using Auth0 that developers should to be made aware of?
Again, many thanks for all your help! 
1 Like