Security concerns on persisting access tokens (JWTs) in web UI

[gkalpak]

The problem

Currently, when a user logs into the web UI, a JSON Web Token (JWT) is returned by the server and stored in the browser's localStorage. A downside of this approach is that, if an attacker obtains permissions to run JavaScript on the website (i.e. via a Cross Site Scripting (XSS) attack), they will be able to access that JWT token and impersonate the user.

While the likelihood of this being exploited is low, since the attacker would first need to identify and exploit an XSS vulnerability, we (at XLTS.dev) would like to start a discussion and explore some alternative (potentially more secure) approaches.

Background

Some security experts recommend avoiding storing sensitive information, such as JWTs, in localStorage and using http-only cookies instead.

For example, Curity's JWT security best practices article recommends against using JWTs for sessions and claims that "using them in such a way may actually lower the security of your applications". It references other articles that detail the downsides of using JWTs for sessions.

Another article by Michelle Wirantono, LocalStorage vs. Cookies: All you need to know about storing JWT tokens securely in the front-end, discusses the pros and cons of using JWTs vs http-only cookies and concludes with the recommendation to store access tokens in memory and store refresh tokens (for OAuth workflows) in http-only cookies. While this does not directly apply in our case, since there are no refresh tokens, it shows a preference to storing access token in memory and preferring http-only cookies over localStorage. It also quotes OWASP's HTML5 Security Cheat Sheet, which recommends against storing "session identifiers in local storage as the data is always accessible by JavaScript" and mentions that "cookies can mitigate this risk using the httpOnly flag".

However, using http-only cookies to store tokens comes with its own set of issues, as cookies are vulnerable to Cross Site Request Forgery (CSRF) attacks.

Auth0's Token storage guide recommends storing access tokens in memory, either using Web Workers or JavaScript closures.

Resources

Here are some useful resources on the subject (most of them already mentioned above):

• JWT security best practices
• Stop using JWT for sessions
• LocalStorage vs. Cookies: All you need to know about storing JWT tokens securely in the front-end
• Cookies vs. Tokens: The definitive guide
• Token storage
  • Browser in-memory scenarios
  • Browser local storage scenarios

Proposal

From what I can tell based on my research, all available approaches for persistent stateful, token-based authentication have pros and cons and there doesn't seem to be a clear winner. Given that switching to cookie-based persistence would involve a significant refactoring of the authentication flow/logic, I am wary of suggesting such a change, but I would like to hear the maintainers' and community's thoughts.

At the same time, I think there is a low hanging-fruit for improving the security posture of the web application for people that are willing to sacrifice a bit of convenience for security: There seems to be a consensus among experts that storing access tokens in memory improves the security of an SPA (at the expense of user convenience, since sessions are not persisted across page refreshes/revisits).

Therefore, I suggest adding a new option in the web section of the configuration to disable persisting of JWTs. This will be off by default, thus preserving the current behavior, but people could opt into the new behavior if they are concerned about security. When the option is enabled, the JWTs will not be persisted in localStorage and will only be kept in memory, thus making it harder to for the tokens to be hijacked.
(If it is decided that this would be a useful addition, we would be happy to work on a PR.)

To recap, I would love to hear the maintainers'/community's thoughts on:

1. Storing the JWTs in localStorage vs http-only cookies (and potentially changing the current authentication flow).
2. Adding a new option to disable persisting JWTs (and storing them in memory instead).

[gkalpak]

@juanpicado or anyone else: Have you had a chance to look at this. Any thoughts?

Would you be onboard with adding an option to only store JWTs in memory?

[juanpicado]

Sorry :( I've been busy, I want to release 6.x this month and I'll back to this topic afterwards, but I'm aware of the situation.

[gkalpak]

No worries. Thank you for the update, Juan 👍
Looking forward to hearing your thoughts (when you have time).

[silverwind]

Storing the JWTs in localStorage vs http-only cookies (and potentially changing the current authentication flow).

One benefit of localStorage is that the attacker needs to go the extra mile of extracting said token out of the localStorage, vs. the cookie which they can directly abuse with fetch, e.g. cookies are a lower barrier of entry for the attacker. Could even encrypt the localStorage for additional obfuscation, but it's just snake oil because a sufficiently motivated attacker will be able to decrypt it.