42

I am learning about JWT for the security of my project, but I have a question. If I recieve the token correctly after I did the login, but someone else (hacker) in other place steals this specific token, can he access to my session? The server that use JWT authentication is able to detect this and protect me? How?

in3pi2
  • 877
  • 1
  • 11
  • 22
  • 2
    Depends on the way the token is used by the server. JWS itself is just a bag of properties and can be used secure or insecure. It does however not bring any new protections to the table. – eckes Mar 05 '16 at 18:06
  • beware that under some (most?) implementations of JWT a token [cannot be revoked](https://stackoverflow.com/questions/31919067/how-can-i-revoke-a-jwt-token) - hence the need for short expiry times – mulllhausen Jul 24 '18 at 09:03

1 Answers1

74

Only the server should know the "secret" that is used to generate the JWT. If someone modifies the data contained in the JWT, the server will fail to decode it. So the server can trust any JWT that it can decode.

However, if a hacker got access to your computer, they could see the JWT that is stored in the browser and use it. This same threat exists w/cookies, so it's not really a flaw of the JWT.

One way to mitigate this threat is the expiration date of the JWT. For a banking app, your JWT might expire after a few minutes. For Facebook, it might expire after a few months. However, there's no bullet proof solution to this if someone gets access to your browser.

Another approach for hackers would be a "man in the middle" attack to intercept the network traffic between client and server and get at the cookie/JWT. The cookie/JWT should always be sent over HTTPS to prevent this.

IMPORTANT EDIT

Finally, to answer the question in your title, "How safe is JWT?": It depends on how you store the token. Local storage is not as secure as using cookies (reference) but cookies can be subject to CSRF or XSRF exploits.

This answer used to say JWT was safer than cookies, because cookies were subject to CSRF attacks. But storing JWT in local storage is not safe either. As a result, I'm no longer storing my JWT in local storage and using well known techniques to mitigate CSRF attacks.

Sunil D.
  • 17,983
  • 6
  • 53
  • 65
  • 1
    You can also pin the client IP or network and user agent. This helps a bit against session stealing (but might also introduce problems when clients use roaming, isp proxies or carrier grade NAT with chanhing IPs). – eckes Mar 05 '16 at 18:04
  • really awesome n simple answer – maq Aug 14 '16 at 14:40
  • 29
    So, where are you storing JWT now and what are the techniques you are using? – Andre Figueiredo Feb 20 '19 at 04:01
  • @AndreFigueiredo you can use session storage instead of local storage – jkettmann Sep 10 '19 at 10:54
  • @jkettmann there is no security benefit using Session Storage instead of Local's. Still vulnerable to XSS. I can suppose author is using HTTP-Only Cookie, but I'd like to see author's thoughts on this.. – Andre Figueiredo Sep 10 '19 at 16:58
  • @AndreFigueiredo According to MDN session storage survives only for that tab/browser session. So definitely session storage will prevent CSRF. I agree that both session-storage/cookie-storage are equally vulnerable to XSS. So to conclude "session-storage" definitely seems safer than "local-storage". – user18853 Dec 10 '19 at 09:05
  • 1
    @user18853 local storage prevents CSRF too. The only difference is how long data is available. In the real world, that is less time to put out sensitive data. From a security perspective, there's no difference, since a user may have the tab always open. – Andre Figueiredo Dec 10 '19 at 14:12
  • Would you agree that cookies HttpOnly prevents 'onerror=...document.cookies...' making it like a header from a JS threat point of view. – Jeremy Chone Mar 01 '21 at 18:16
  • Since introduction of SameSite attribute Cookies are no longer vulnerable to XSRF. – mvmn Mar 08 '22 at 20:17