JWT stands for JSON web token
the common definition says that it is an open industry standard RFC 7519 method for representing claims securely be...
For further actions, you may consider blocking this person and/or reporting abuse
About the conclusion of the article:
HttpOnlyflag), whereas your JWT in localStorage can be read by any JS, making XSS a much higher risk (well, in any case, if you have an XSS, it's gameover, unless maybe you actually only keep things in a non-global variable, i.e. not localStorage)It's not about what you use to authenticate your user, it's about how you put it.
Also, you're not tackling logout, aka revoking your JWT. To do that, you'll need to store things server-side and querying them on each client request. If your JWT tokens have a very short expiration (like the 2 minutes in your sample code), this is OK, but this will negatively impact UX (having to sign in again every 2 minutes) or security (keeping the user credentials in memory client-side).
About that sample code, you're not putting the user's password in the JWT are you ‽
About JWTs themselves, you can make an equivalent system (cryptographically sign, or encrypt by the way, some data that you also base64-encode) without the drawbacks of JWT (signature details "negotiation" through the JWT header).
Some reading about JWTs:
That last article also tackles the "accessing the database issue":
Thanks a lot for sharing your knowledge about the subject,
thanks for articles as well,
The post was a general presentation about JWT and the way it works and the main practices to make it more secure ( I admit as well that storing it in localStorage is risky unless we use short expiration time, which in some cases ruins the user experience )
I believe that using tokens vs cookies will always last as a huge debate, yet I admit that in some implementations, its better to use cookies over tokens for better user experience as you said.
Thanks again for sharing your knowledge about the subject.
Couldn't you interpret the original requester IP and place it into the JWT? If the JWT signs the contents, to later verify the contents, couldn't you prevent session hijacking? Otherwise, simply storing the JWT in cookies or localstorage could result in an attacker stealing the JWT.
JWT is something I want to learn more about. Please let me know if I am missing something! Great article!
Thanks Brent, well to be honest, I didn't test it as a solution, yet I read about it in many articles, the idea seems to solve the problem, in fact some solutions tend to use IP address and the UserAgent of the client.
I currently started studying cyber security, and I can tell you that nothing, and I mean literally NOTHING is unhackable... ( IP addresses can be spoofed )
it's simply about trying to make things safer harder to break through.
Thanks for the honest reply. I honestly think that rotating the session often and logging IP's/user-agents/domains is the best way to prevent piggybacking or session hijacking. Ip addresses and domains can be faked. However, over the open web this can be quite difficult (in peer to peer communications such as API's). Rotating would invalidate any stolen sessions before they could be used. The IP logging could be used to determine if access is coming from an unknown address and trigger a 2FA response. The domain would be useful for API based authentication (peer to peer).