JWT - Storing them in LocalStorage vs SessionStorage

Question

Thanks for taking the time to read my question! I've been researching about JWT's today. Originally I thought the modern consensus was that JWT's are open to the two main types of attacks unless stored in a httpOnly cookie (which can only be issued by the server).

Background:

However, I learned today that as long as you don't put any confidential user information in the JWT payload, it's okay if a hacker gets access to the token and de-encodes it, because at most it may just show a user's unique ID. I can handle grabbing the user password and other confidential information on the server once the server verifies the JWT and grabs the ID inside the payload's sub key.

Nonetheless, I am still not 100% clear on what happens if a hacker intercepts a token MID request/response for instance, and the token never expires. From my understanding, the hacker will be able to gain access to a user's account and mess around on the user's page, and there's no real way of revoking the token from the hacker, even if the user reset his or her password because the hacker STILL has the token and the server isn't smart enough to realize that it's not the intended user.

---

Anyways, I realize that I cannot use httpOnly cookies, or any cookies for that matter because I am using the backend server only as an API, it cannot deliver cookies cross server to my front end client facing program (React, for instance).

In this case, there seems to be only two places to store your auth JWT: LocalStorage, or SessionStorage... I guess most people will go with LocalStorage on account of the fact that closing the browser will not destroy the token.

My main question is this:

Being that LocalStorage or SessionStorage are the only 'reasonable' places to store a JWT, is one safer than the other, and why?

THANKS!

Answer 1

Both LocalStorage and SessionStorage are defined in the same specification and the difference between them is only about the lifetime of the data that is placed on each store.

From a security standpoint they are mostly equivalent. You could argue that since SessionStorage has a shorter lifetime and automatic cleanup upon the user terminating the session then it's somewhat more secure, but that's about it. Also note that closing the browser may not destroy the contents of session storage; session storage is tied to the lifetime of a browsing context.

The specification clearly notes this:

The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent may support resuming sessions after a restart.

_{(emphasis is mine)}

You already excluded cookies due to your specific requirements, but if you want to know a bit more about the security considerations of storing tokens client-side you should read the Where to Store Tokens? section of Cookies vs Tokens: The Definitive Guide.

---

In relation to what happens if an attacker gains access to a token what you said is mostly true, if the token is what's known as a bearer token than the only thing needed to authorize the request is to know the token. This means that the server will accepts requests from anyone that has the token. Because of this it's recommended that tokens have a shorter lifetime in order to minimize the impact of leaks.