What Happens If Your Jwt Is Stolen?
What happens if a JSON Web Token is stolen or compromised? What are the security considerations you need to understand? In this post, we’ll look at what JWTs are, and what happens when they’re stolen or compromised.
debashis_deb
Nice article !
Naresh Waswani
Any thoughts on - How to handle “Close all sessions from all devices” use case where JWT is used for authentication ?
Randall Degges
The only way to do it is to maintain a centralized database of issued tokens. This way you can then have a token ‘status’ like ACTIVE, DISABLED, etc. When each request comes in with a JWT you can then check the status of the JWT in your database and see whether or not it should be allowed.
So basically: store JWTs in a central database and check against that database on each request. When a user logs out you can lookup all the JWTs that were created for that user and change their status to DISABLED so they can no longer use it.
This approach requires centralization, but is the only sure-fire way to handle it. There is no good “stateless” way to do this that works in all scenarios.
Luciano Mammino
Also tokens can be brute forced if you use weak secrets. When that happens the situation is even worst. An attacker that knows the secret will be able to generate new tokens embedding all the info he wants there (impersonating other users or escalate his permissions). I talked about this here: https://community.risingsta…
Kedi Agbogre Ripa
What I do is I add a new field to the users table containing a GUID, which will be included in the token’s payload. When logging in, you generate a token including this GUID in its payload, and then store the GUID in the users table. Upon logout, you can then refresh the user’s GUID so all previous tokens are invalidated. No need to store the entire token in the database.
Shafkathullah Ihsan
Does stealing token from client-side is as hard as stealing username or/and password from form on https, or is it much simpler? Could anyone compare?
Alex Mills
OK BUT HOW TO PREVENT JWT from BE STOLENNN? thx 
Michael Farley
This completely defeats the purpose of JWTs; you may as well just use a simple user-id if you’re just going to do a database lookup on every call. The OP suggested a better option anyway of maintaining a lookup of only the revoked tokens rather than tracking the state of each and every token.
Randall Degges
This does completely defeat the purpose of JWT, but if you read through @kediagbogreripa 's response, you’ll see it doesn’t solve the issue. I’ve commented on this before.
Let’s say you do what Kedi is suggesting: generate a GUID and store it in the users table in your DB, then also include that data in the JWT payload. How do you check to ensure the token isn’t revoke when a user uses the token to authenticate?
Hint: you must send that GUID to the place where your central GUID is stored: the user table in the database! It ends up re-centralizing no matter what you do, unless your solution involves storing token lists (or GUIDs, which IMO is more effort than just storing a token itself) on the edge and invalidating them that way.
But in either circumstance, there’s no way to avoid centralizing JWTs if you want to be secure 
Erik Thiart
Alright so how would you implement JWT on a SPA (client side JS).
Example, secure and API being used for AJAX.
Rajesh Kishore
Best explanation, good job
Ítalo Teixeira
This can not always happen if we create a key for each client.
Stephan
Then you have effectively lost all the benefits of jwt. You have to look up the key on every request, so you can just as well fetch the user data from your db.
Ahmed Shaker
the traditional way to use JWT
1- login with username and password and receive token
2- store token into web storage
3- read this token and send it with each request
is this way is secure or there is any other way
Matt Raible
This way is secure if you have a good content security policy that doesn’t allow any third party scripts. If you allow 3rd party scripts, and they get compromised, they may be able to read your web storage and access data on your behalf. That’s why you should use short-lived JWTs. OAuth 2.0 / OIDC provides a better solution because it allows short-lived access tokens and long-lived refresh tokens.
Sandesh Magdum
Nice article!
I have two queries though:
1. What are Symmetric Vs Asymmetric JWT tokens and what are security impacts while choosing either of these two?
2. Can a Node.js based application mechanism can prevent stealing of JWT tokens?
Renato Byrro
A better way to handle that (without losing the stateless mode of JWT) would be using a pool of known secrets and using an algorithm that can determine which secret to use depending on the user ID or any other information that is available in the public part of the token.
Judothat
It s easier
Ron
You’re calling jwt.compact() twice; the first time, you’re assigning the return value to a variable named “token”, but not using that variable.
Also, there is no such thing as “server-side cookies”. Cookies are strictly client-side. There would be no difference in security between storing a token in a cookie, and storing a token in HTML5 local storage.