18

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)

Tim
  • 283
  • 1
  • 2
  • 5

2 Answers2

8

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).

Daniel Szpisjak
  • 1,825
  • 10
  • 19
  • 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 04 '17 at 08: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 04 '17 at 08: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: https://github.com/firebase/php-jwt/issues/83 (user BonnieDoug) – Tim Aug 04 '17 at 08:19
  • So what I want is called "Sliding sessions" apparently: https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/ I still can't see the downsides of this approach. – Tim Aug 04 '17 at 08: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](http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/) about the downsides. If you can live with the tradeoffs your solution is perfectly fine. – Daniel Szpisjak Aug 04 '17 at 08:46
  • It's a old but helpful link. I wanted to know what are "classical" session management techniques that we are using this context. As, i understand by "classical" we mean matching username, password and generating a session id which will be mapped to the user id which can be managed as required. – quintin May 30 '19 at 05:28
  • 1
    No, classical session management means just managing a session (create, update, delete). It doesn't have to do anything with user/password check. You already have an authenticated user, as soon as a request arrives with a valid JWT token (the token itself means a user has authenticated somewhere else - and you trust that "somewhere else" is a credible source to claim that). You have to create/update/delete the session for that user to have the functionality you want. Re-issuing a lot of JWT tokens per user, could introduce a possible security vulnerability, due to a lot of active tokens. – Mladen B. Sep 06 '19 at 08:32
  • More info on this answer: https://stackoverflow.com/a/25810348/2428861 – Mladen B. Sep 06 '19 at 08:45
0

If token expires then regenerate new token only if the difference between expiry time & current time is less than inactive period (session idle time).

If difference is more than inactive period then ask for login and authenticate user and generate the token.

If difference is less than inactive period then using payload & header apply signature so that new token get generated.

Gopal Sikhawal
  • 1
  • 1