top of page

OAuth 2.0 | JSON Web Token (JWT) | What if JWT is stolen?

What if someone stoles my token? The application or malicious user can impersonate me and can do everything authorized with that token? How will my application invalidate such a token? Is there a way to identify such a request? Isn't it a big security issue?


In today's article, we're going to talk about this.




Firstly, JWT itself does not know who is using it, therefore if a malicious user gets hold of it; then it's clear all operations authorized with that token can be performed. Therefore, we need to see what we can do to minimize this damage.


  • Expiration Timestamp: We can keep JWTs to be short-lived by adding a shorter expiration timestamp. Therefore, at least after expiration, the token can be rejected. We studied expiration claim exp in one of the previous articles https://www.techlearnings.org/single-post/oauth-2-0-json-web-token-jwt-claims

  • BlackListed JWTs: We can maintain a list of JWTs on the server-side which are outright rejected whenever received. Therefore, simply adding the stolen JWT to that list can prevent further damage.

  • Secret Key: From previous articles, we're aware of the importance of a secret key in token structure and validation. We can simply change the secret key, but this would also invalidate all issued tokens.

  • Client Credentials Update: The client should change the credentials at the earliest. It's like when username & password are compromised then one should immediately change the password else the malicious user can simply change the password as he/she might have required authorization now.

  • Try to get to the root cause of how the token was compromised on top priority else who knows even after expiry, the malicious user might be able to generate a fresh token.


We might want to proactively monitor requests to avoid such situations. As we say in the medical world, "Prevention is better than cure". A couple of points to add here -


  • Monitor unusual spikes in traffic. e.g. If we receive 10 requests/minute from a client, but if we start receiving 100 or requests above a configurable threshold, then we can get an alert/ take some automated or manual action basis alert.

  • Monitor requests for unusual geographical locations. Similar to the way we do in the Credit/Debit Cards systems to prevent theft.

Would like to end today's article with a question - What if a refresh token that has normally larger expiry times is compromised, what will you do in that case of the above steps or any other way that you wanna suggest?


Comments are welcome!


Do stay connected, LinkedIn, Facebook, Twitter, YouTube wherever you feel comfortable. See you soon with next article!


Mentioning other OAuth articles already published as a handy reference guide for further learning. Do check out in case you missed/want to re-read.



Happy TechLearnings!

Tags:

Comments

​
bottom of page