5

In general it's recommended not to store refresh tokens in local storage. The Auth0 documentation advises against it.

Even though I am aware of the underlying threats, what I am not aware is if there are any alternatives as to how to store those tokens in order to have persistence within the duration of a user's session when the API server is different than the client. If the tokens are only stored in memory, then the user will have to login every time he closes a tab for example and later on visits the site again.

Finally, I think anyway the refresh token rotation would mitigate the risk of having the tokens stolen. So in the lights of that, the above recommendation doesn't look very valid.

tturbox
  • 101
  • 1
  • 4
  • The refresh token is not supposed to survive user session. If the user logs out (i.e. the session is destroyed), the refresh token becomes invalid. Did you mean that refresh token should be persisted between browser/tab closures? – bhorkarg Mar 27 '20 at 08:43
  • indeed, i've worded it better – tturbox May 09 '20 at 13:57

1 Answers1

1

Storing the refresh and access token is in JavaScript memory is generally considered much better than cookies or other browser storage.

You still don't need to worry about asking the user to login every time. The authorisation server (Auth0 in your case) maintains its own session (SSO Session) behind the scenes which is persistent. So it survives even if the user closes the browser.

This means that even if you have "lost" the refresh token stored in memory (e.g. if the user closes the tab), you just need to re-run the authorisation code flow to get new refresh and access tokens (i.e. redirect the user to the authorisation server). This should be silent to the user (i.e. they won't see the login screen) because of the same SSO session that is maintained by the authorisation server would still be active.

bhorkarg
  • 432
  • 2
  • 12
  • In [oauth2.1-draft](https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-9.3.1), it states that authorization servers shouldn't (ok, no must not) automatically process auth requests without user interaction. Maybe depending on the authorization server to automatically process those requests is not a futureproof solution? – tturbox May 07 '20 at 21:40
  • 1
    How does the server identify the session of the browser if the tokens have been lost? – stoft Mar 31 '21 at 07:27
  • 1
    Could you please explain why JavaScript memory is generally considered better than cookies or other browser storage for access tokens? If you have malicious JavaScript running (because of XSS), then can't that JavaScript read the memory anyway just as it can the local storage? – Andrew Bate Sep 17 '21 at 00:17