Skip to main content
Information Security

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

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. Commented 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. Commented 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) Commented 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. Commented 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. Commented Sep 6, 2019 at 8:32