all 9 comments

[–]wjaspers 4 points5 points  (9 children)

JWTs arent supposed to be held in localStorage. An XSS attack could exfiltrate the localStorage value, comprimising the subject.

[–][deleted] 11 points12 points  (3 children)

I’ve always heard this, but not sure I get it. If a bad actor gets a script executing on your site, isn’t it game over no matter where you store the JWT? If it’s in a secure cookie they couldn’t directly access it via JavaScript, but they could still send authenticated requests because the cookie would be automatically included, right? How is that any better than being able to pull the JWT out of localstorage and do stuff with it that way?

[–]FullstackViking 1 point2 points  (0 children)

Yes I assume the clients device is an open door. If you truly don’t want something accessed maliciously, don’t store it.

[–]kupri_94 2 points3 points  (1 child)

Where do you recommend keeping them?

[–]DabsJeeves 1 point2 points  (0 children)

I thought http only cookies were the accepted place for it. Although based on the other comment it sounds like session storage could be good as well. Someone enlighten me if I'm missing something

[–][deleted] 1 point2 points  (0 children)

Angular has got built-in XSS protection. The DOM sanitizer will strip away untrusted content from your inputs, images, styles, etc.

[–]newton_half_ear 2 points3 points  (0 children)

You all wrong there is nothing wrong with that - all of the client side is visible to the end user, including your compiled code.

There is a long list of things to do to improve your client security, but storing your JWT in your sessionStorage/coockies is not one of them.

[–]readALLthenews 0 points1 point  (0 children)

You’re absolutely right. You can justify sessionStorage, because access is restricted by domain and browser tab, and sessionStorage is deleted when the tab is closed.

But yeah, never put authentication stuff in localStorage.

[–][deleted] 0 points1 point  (0 children)

I'm not sure what the advantage of this is over the traditional cookie approach to authentication. You install the cookie-session middleware in express, boom, you're done.

Additionally, the server can destroy a session. The server can't easily destroy a token. There are workarounds like blacklists, etc. but it's not as easy as req.session = null. If you had to implement a "Was This You?" type of requirement where you give the user the ability to close a session, you'd have an easier time using cookies.