You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Session not cleared if user uses Back after logout #562
After calling logout the user is redirect back to our login page, but if they go back with their browser they can get back into the application and perform authenticated actions. Calling refresh at any time throws them out of the application, and the auth0 logs show a successful logout.
To add more mystery to this, it does not happen consistently. For example, if the developer tools are open in the browser, the problem goes away and going back throws the user onto the login screen.
Reproduction
login
logout
press back
find yourself logged in again.
It seems to be mitigated by having the developer tools open, but is pretty much consistent in normal use. Also unable to replicate it on a localhost dev build.
This is a performance feature of Chrome (and Safari & FF) called Back/forward cache
When you click the Back button, Chrome loads the previous page seemingly in an instant, because the entire page is restored from memory - there's not much the SDK can do, but you can disable bfcache on your browser if you don't want the feature.
Thanks for sharing that link @KlausVii - you can certainly do that on your application if you want.
I can't think of a good reason why we wouldn't add something like that to the Spa SDK (at least behind a config option) - let me discuss it with the team.
Reacted by Klaus Viisainen, Vesko, Benjamin Piggin, dmdum and Gleb Haranin
Reacted by Klaus Viisainen, Vesko, Benjamin Piggin and dmdum
I only ask because I'm investigating this and can't reproduce it on localhost or another domain and I'm wondering how bfcache works with redirects (cross domain or otherwise)
If you test it lmk if it works also, if you can share a HAR file (with secrets redacted) that demonstrates the issue I'd also be interested in looking at it.
Also looking to get this addressed. The event listener workaround is not working for me as the cookie still seems to exist on back tap, or at least in the time that the code checks it. I even tried an interval to check it in case it was a timing issue where the cookies were not cleared by the auth0 client logout call yet.
Alternatively we could always reload on pageshow persisted=true check but that is a burden on the user.
For now, we have been unable to reproduce this, but believe we have a bit of missing information.
Can someone provide some information for us to help reproduce this, in order for us to consider how to address this?
Are you using auth0-react in your application?
Are you using auth0.js in your application?
Are you using lock in your application?
To avoid any confusion, it would help if someone could share an exact reproduction of a client application that allows to reproduce the behavior.
@zebapy I am asking the above because I noticed the information you shared with our team through different channels indicates the use of auth0.js (e.g. it's set as the Auth0Client header on the call to /authorize), and you mention lock. Which I am trying to understand how they fit in the story here.
Additionally, I think there may be other factors at play here that are important to get some information on:
Are you using the new or classic login experience on Auth0?
In case you are using the classic login experience, which login template are you using if you are using?
Currently using: @auth0/auth0-react": "2.2.4".
Not using auth0.js.
Not using lock
Currently this only occurs in Firefox and only with the built app, it does not occur when the dev server is running. After logging out, once Auth0 has redirected back to our app, if the user clicks the back button it looks like it is loading the page from cache (I assume this is the bfcache as I dont see any network requests other than icons in the network tab). I also noticed that here:
It only dispatches the "LOGOUT" action if you specify an openURL, ie. if you let auth0 do the redirect back to the client app it doesnt dispatch the action and and doesnt set isAutheticated to false. I assume this is done as its going to load a new copy of the client after the redirect anyway where the isAuthenticated status will be setup fresh anyway. But if the user clicks the back button and the browser uses the bfcache then the page will be repopulated with the Auth0Provider still having isAuthenticated set to true. The app is then accessible for a bit, I assume until something checks the authenticated cookies which were correctly removed on logout.
In browsers where it doesn't rerender the pages on clicking back like chrome I see that on clicking back I get the logout url appearing in the network tab so Im assuming it isnt loading the page from the bfcache.
Im probably barking up the wrong tree but would it help if the client dispatched the logout action even if the user hasn't provided an openUrl in the logout options?
Alternatively is there something that is meant to prevent the browser using the bfcache when clicking back after logout?
p.s. - I have used the listener/event mentioned above to force a reload if the page is reloaded from the bfcache as a workaround.
We discovered this behavior just the other day, and our evaluation led to pretty much the same conclusions as #562 (comment). Since that was written, however, it looks like Chrome is now more aggressive with bfcache and is causing the same security issue, where logging out is thwarted whenever the back button is used which restores the Javascript heap state. (Including, presumably, the access token and some state that indicates that the user is logged in, although I'm not familiar with the auth0 internals at all here.)
The "pageshow" event listener does seem to be working as a workaround.
asynclogout(options?: LogoutOptions){if(!this.logoutFromAccount)thrownewError("Auth0 not initialized");// Workaround for Auth0, when logout is triggered will clear browser cache for bfcache problems.window.addEventListener("unload",()=>{});returnawaitthis.logoutFromAccount(options);}```
Hey, picked this up while going through older issues. The problem is bfcache restoring the frozen JS heap with stale isAuthenticated: true since LOGOUT is never dispatched on default redirect.
Looking at handling this with a pageshow listener in Auth0Provider that calls checkSession() when event.persisted === true. Will see where it goes.
Activity
adamjmcgrath commentedon Aug 24, 2023
Hi @KlausVii - thanks for raising this
This is a performance feature of Chrome (and Safari & FF) called Back/forward cache
When you click the Back button, Chrome loads the previous page seemingly in an instant, because the entire page is restored from memory - there's not much the SDK can do, but you can disable bfcache on your browser if you don't want the feature.
KlausVii commentedon Aug 24, 2023
Ah thank you for the explanation @adamjmcgrath
Should we do something like this event listener to force a reload?
adamjmcgrath commentedon Aug 25, 2023
Thanks for sharing that link @KlausVii - you can certainly do that on your application if you want.
I can't think of a good reason why we wouldn't add something like that to the Spa SDK (at least behind a config option) - let me discuss it with the team.
adamjmcgrath commentedon Sep 13, 2023
Hi @KlausVii - I'm just doing some more investigation into this
Are you able to share a link where I can reproduce this behaviour?
Also, did you try adding the event listener and did it resolve your issue?
KlausVii commentedon Sep 13, 2023
@adamjmcgrath Sorry our application is not open to the public, so cannot really share a link.
I have not tried the event listener as of now, we parked this kind of hoping your fix would resolve it 😅
I'll let you know if/when I find time to test this.
adamjmcgrath commentedon Sep 13, 2023
np, thanks @KlausVii
I only ask because I'm investigating this and can't reproduce it on localhost or another domain and I'm wondering how bfcache works with redirects (cross domain or otherwise)
If you test it lmk if it works also, if you can share a HAR file (with secrets redacted) that demonstrates the issue I'd also be interested in looking at it.
zebapy commentedon Feb 14, 2024
Also looking to get this addressed. The event listener workaround is not working for me as the cookie still seems to exist on back tap, or at least in the time that the code checks it. I even tried an interval to check it in case it was a timing issue where the cookies were not cleared by the auth0 client logout call yet.
Alternatively we could always reload on pageshow persisted=true check but that is a burden on the user.
frederikprijck commentedon Mar 14, 2024
Thanks everyone for the patience here.
For now, we have been unable to reproduce this, but believe we have a bit of missing information.
Can someone provide some information for us to help reproduce this, in order for us to consider how to address this?
To avoid any confusion, it would help if someone could share an exact reproduction of a client application that allows to reproduce the behavior.
@zebapy I am asking the above because I noticed the information you shared with our team through different channels indicates the use of
auth0.js(e.g. it's set as the Auth0Client header on the call to/authorize), and you mention lock. Which I am trying to understand how they fit in the story here.Additionally, I think there may be other factors at play here that are important to get some information on:
michael-pascoe commentedon May 12, 2024
Hi @frederikprijck ,
Im having similiar issues.
Currently using: @auth0/auth0-react": "2.2.4".
Not using auth0.js.
Not using lock
Currently this only occurs in Firefox and only with the built app, it does not occur when the dev server is running. After logging out, once Auth0 has redirected back to our app, if the user clicks the back button it looks like it is loading the page from cache (I assume this is the bfcache as I dont see any network requests other than icons in the network tab). I also noticed that here:
https://github.com/auth0/auth0-react/blob/main/src/auth0-provider.tsx#L202
It only dispatches the "LOGOUT" action if you specify an openURL, ie. if you let auth0 do the redirect back to the client app it doesnt dispatch the action and and doesnt set isAutheticated to false. I assume this is done as its going to load a new copy of the client after the redirect anyway where the isAuthenticated status will be setup fresh anyway. But if the user clicks the back button and the browser uses the bfcache then the page will be repopulated with the Auth0Provider still having isAuthenticated set to true. The app is then accessible for a bit, I assume until something checks the authenticated cookies which were correctly removed on logout.
In browsers where it doesn't rerender the pages on clicking back like chrome I see that on clicking back I get the logout url appearing in the network tab so Im assuming it isnt loading the page from the bfcache.
Im probably barking up the wrong tree but would it help if the client dispatched the logout action even if the user hasn't provided an openUrl in the logout options?
Alternatively is there something that is meant to prevent the browser using the bfcache when clicking back after logout?
p.s. - I have used the listener/event mentioned above to force a reload if the page is reloaded from the bfcache as a workaround.
Thanks for your time
Michael
dmateertf commentedon Feb 7, 2025
We discovered this behavior just the other day, and our evaluation led to pretty much the same conclusions as #562 (comment). Since that was written, however, it looks like Chrome is now more aggressive with bfcache and is causing the same security issue, where logging out is thwarted whenever the back button is used which restores the Javascript heap state. (Including, presumably, the access token and some state that indicates that the user is logged in, although I'm not familiar with the auth0 internals at all here.)
The "pageshow" event listener does seem to be working as a workaround.
nichita-pasecinic commentedon Dec 12, 2025
+1
buzadandeveloper commentedon Feb 3, 2026
yogeshchoudhary147 commentedon Mar 20, 2026
Hey, picked this up while going through older issues. The problem is bfcache restoring the frozen JS heap with stale
isAuthenticated: truesinceLOGOUTis never dispatched on default redirect.Looking at handling this with a
pageshowlistener inAuth0Providerthat callscheckSession()whenevent.persisted === true. Will see where it goes.nichita-pasecinic commentedon Mar 20, 2026
to work around bfcache: