On the jwt.io inroduction page, it sites HTML5 Security - OWASP Cheat Sheet Series when explaining why we should not store our jwt in browser storage. That leaves cookies as our storage mechanism when using a browser. But it then goes on to recommend that we send the jwt in the Authorization header which would mean that the cookie cannot be HTTP-only since it must be read by the client-side JS in order to put the jwt in the request header. The whole point of using the cookie was to avoid letting malicious JS read the value from local storage, but if the cookie can be read by JS it seems like it is no better than local storage. The secure and same-site cookie flags also don’t benefit us in this case since we are just extracting the value and putting it in the request header.
I feel like I am missing something and would appreciate any clarification as to the recommended use of JWT between a browser client and api. Thanks!
What protects this in-memory cache from having the same issues as the browser storage mechanisms? For example, wouldn’t that in-memory cache still be readable by malicious JS on the client?
I’m not familiar with cache.ts but it looks like an in-memory object/array that is simply storing objects. This is fast and great for a single HTML page but when navigating to a new page or new tab, won’t you lose this context?