loading...

re: LocalStorage vs Cookies: All You Need To Know About Storing JWT Tokens Securely in The Front-End VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Hi Michelle, really great article! What always confused me about httpOnly cookies and JWT is that the frontend app is missing a big benefit of JWT,...
 

Hi Marko, Putri here – Michelle's cofounder.

That's an interesting suggestion! I don't quite understand how the frontend would miss being able to read the claims/custom data in the JWT using option 3. By storing the access token in memory, you can decode and read the claims in the frontend whenever the access token is available. When the access token is not available in memory (after a refresh/change tab), you can use a function that will refresh the access token, and now you have the access token available again in memory and you can read/decode it in the frontend.

Splitting the JWT might be a useful option if the above solution doesn't help. Let me know what you think :)

 

By storing the token in memory, you risk compromising it by means of xss. The damage is contained since the token is short-lived, but still a window of opportunity exists.
We can either accept this risk or add considerable complexity to reduce it. What do you think?

That's true, storing in memory is still prone to XSS attack, it's just harder for the attacker to find it than localStorage.

Splitting the JWT into 2 cookies where the signature is in an httpOnly cookie, but the rest of the JWT is accessible to JavaScript makes sense. This means that the frontend can still access JWT except for the signature.

I think it's up to the website to determine what kind of attack factor that they're trying to mitigate against to decide whether they need the upgrade in security.

Code of Conduct Report abuse