10

I have a stateless webapp that uses a JWT token. Eventually it will expire - which is OK, but I don't want it to expire while the user is working. Instead, I would like the token to expire after a certain time of inactivity.

Let's say my token is valid 60 minutes, Is it ok to send a new JWT on every request ? That way, as long as the user is working, his token will be renewed (as long as he makes a request per hour), but after more than an hour of inactivity, the token will expire.

I don't want to use stateful refresh tokens. A timer on the client's side would eventually delete the token as soon as it expires.

Am I missing a major flaw with this approach ? (except obvious performance impacts due to more frequent DB accesses)

5

JWTs are self-describing integrity checked tokens. They are not designed for the use-case you described. JWTs cannot be expired on demand, nor can their validity be extended.

What you can do with these tokens is issue new tokens, just like you described. This will not invalidate the old ones. You will end up generating lots of tokens which will expire by themselves.

Am I missing a major flaw with this approach?

JWTs are not designed for a full-blown session management. They come with various tradeoffs. One of these is the inability to update them or expire them on-demand. The workaround you described works perfectly. I wrote a short post about session management, which should help you decide whether to make the tradeoffs.

In my opinion, you should probably move to the "classical" session management model. It supports idle timeouts and you also won't end up with lots of "sessions" (tokens).

  • Thanks. What did you mean by "What you can do with these tokens is re-issue them. This will not invalidate the old ones. You will end up generating lots of tokens which will expire by themselves." ? You later say "the inability to update them". I am not sure I understand. – Tim Aug 4 '17 at 8:09
  • 1
    @Tim, You cannot update the token itself. By reissuing, I mean you can issue a new one. I edited to post to make it a bit more clear. – Daniel Szpisjak Aug 4 '17 at 8:16
  • Well, isn't that what I proposed in my question ? re-issuing a new token on each request ? I am confused. I found the same approach here: github.com/firebase/php-jwt/issues/83 (user BonnieDoug) – Tim Aug 4 '17 at 8:19
  • So what I want is called "Sliding sessions" apparently: auth0.com/blog/… I still can't see the downsides of this approach. – Tim Aug 4 '17 at 8:33
  • @Tim, With the sliding session approach you can closely emulate the "classical" session management with support for inactivity. The cost is additional complexity and additional tradeoffs. Here is a great article about the downsides. If you can live with the tradeoffs your solution is perfectly fine. – Daniel Szpisjak Aug 4 '17 at 8:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.