Session not cleared if user uses Back after logout

[KlausVii]

Checklist

• The issue can be reproduced in the auth0-react sample app (or N/A).
• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

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

1. login
2. logout
3. press back
4. 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.

Additional context

This is our auth provider

  const onRedirectCallback = (appState?: AppState) => {
    navigate(appState?.returnTo || window.location.pathname);
  };
  ...
      <Auth0Provider
        domain={config.auth0.domain}
        clientId={config.auth0.clientId}
        authorizationParams={{
          redirect_uri: window.location.origin,
          audience: config.auth0.audience,
        }}
        onRedirectCallback={onRedirectCallback}
        useRefreshTokens
        cacheLocation={config.auth0.cacheLocation} // undefined expect for e2e tests
      >

auth0-react version

v2.2.1

React version

17.0.2

Which browsers have you tested in?

Chrome

[adamjmcgrath]

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]

Ah thank you for the explanation @adamjmcgrath

Should we do something like this event listener to force a reload?

[adamjmcgrath]

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]

Hi @KlausVii - I'm just doing some more investigation into this

login
logout
press back
find yourself logged in again.

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]

@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]

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]

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]

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?

• 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?

[michael-pascoe]

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]

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.