19

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)

Improve this question

2 Answers 2

Reset to default
9

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

Improve this answer
8
  • 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, 2017 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, 2017 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, 2017 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, 2017 at 8:33
  • 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 6, 2019 at 8:32
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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .