3 ms·
Perhaps I am missing something but I really don't see the point of storing it in localStorage or sessionStorage over cookies what so ever. 1. You have to write
by mkohlmyr 10y ago
Perhaps I am missing something but I really don't see the point of storing it in localStorage or sessionStorage over cookies what so ever.
1. You have to write code to provide the authentication values in all requests.
2. The GET request for the initial page render can't possibly be authenticated.
Why not cookies? Other than that I agree. I really don't see the point of following the JWT spec or using an implementation of it when it has been shown that these implementations are poor (problems with none algorithm & asymmetric keys).
Fundamentally, what we are talking about is simply a claimed identity, verified and signed by your backend. This is a sound principle. Just implement that and your attack surface is considerably smaller.
- hardwaresofton 10y agoThe reason I wanted to try this scheme was to finally remove the little difference in authentication method between web frontend and commandline/mobile API client... OWASP says not to do it (https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage_.28a.k.a._Offline_Storage.2C_Web_Storage.29 https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#L...) but the stated reasons are kind of vague/I'm not sure the reasoning is sound. If someone has physical access to the machine, all bets are off, and if a XSS vuln happens, pretty sure people can get whatever information they're looking for (including the cookie) anyway. The only real objection was the inability to restrict to HTTPS (path based, everything is just based on same origin regardless of scheme I think), however same origin policy still applies like normal. I wasn't trying to recommend localstorage over cookies, more like just trying to see if there's any huge blindspot I was missing, everywhere I look says not to do this, but the reasons were never very satisfying.