19

I'm here because I wasn't satisfied with what I found on google.

I am generally building SPA's, so for me the process was simple: At succesful login generate a jwt and use it for every request I make from the client.

Someone told me that I should refresh that token and send back a new one for every request I make. Does this make sense for me to do? I mean, if someone is trying to hack me, sniffing the requests will give the hacker the same tokens I receive, so what's the catch?

I mean, what if I launch a request before another one is finished? Teoretically I would send the same token twice and one of the requests will be rejected.

How is this correctly handled? I'm sure there is more to this than what I could think myself.

John
  • 1,081
  • 1
  • 9
  • 34
  • Why would one of the requests be rejected? Both tokens can remain valid until expired right? Unless you implement some kind of token exchange mechanism. – Aert Nov 27 '18 at 09:09
  • Put client's ip address in access token. And check if request coming from same ip address or not. you don't need to worry about stolen access token. also set an expire date. – Erçin Dedeoğlu Apr 18 '19 at 07:09

1 Answers1

31

It is a compromise between security and convenience.

No, you don't need to refresh the token on each request. But you definitely want your JWTs to expire at some point. This is to protect you from JWT theft where malicious user could use stolen access token to gain access to target resource indefinitely.

Here is what you can do to handle token expiration:

  1. Implement a refresh token flow. You will issue an access JWT and a refresh JWT when authenticating. Once access JWT has expired you will use refresh JWT to obtain new access JWT.
  2. Implement sliding expiration. After the half of the JWT validity time has expired you would issue a new JWT. An example of it can be found here. I would recommend to include a deadline to when a token can be expired. For example, initial token validity is for 20 minutes and deadline is 8 hours. After 8 hours of sliding expiration you will stop issuing new tokens.
Marko Vodopija
  • 578
  • 6
  • 12
  • 10
    1. Can we assume that refresh token can also be stolen, like access token? What we would do in that case? 2. For sliding expiration, the attacker can get new access tokens in the same way as a legitimate user would. What should we do in that case? – nihartrivedi810 Feb 03 '18 at 06:26
  • 3
    @nihartrivedi810 If the refresh token is stolen, it can be blacklisted on the backend, this prevents the token being used to generate a new access token, the issue with access tokens is that they're not checked against any DB. – Alex Catchpole Feb 27 '18 at 11:01
  • 1
    So, it means I have to store information related to refresh tokens in my database, while access token will not be stored in the database? @AlexCatch – nihartrivedi810 Feb 27 '18 at 19:26
  • 1
    @nihartrivedi810, yes exactly. Your refresh token is what you use to generate new access tokens that your api can validate without database calls. – Alex Catchpole Feb 28 '18 at 09:09
  • 2
    this is very helpful. But when should the server issue a new refresh token? or how to know if it needs to be blacklisted – chris May 04 '20 at 14:07
  • Typically whenever user changes credentials, requests log out of all devices, a security incident is registered through some means, etc. – Jacek Gorgoń Sep 04 '20 at 11:33