9 comments

[ 8.3 ms ] story [ 29.7 ms ] thread
100% FUD.

  the client could simply ignore it. All prior tokens would 
  still be valid.
No they are not. Also the same applies to sessions, sessions should be refreshed, too.

    To clean up, your application may null out the session    
    or remove the persisted value from the data store. The   
    result is the same; no more session.
The same with JWT.

    The data is cryptographically signed with a Hash-based Message 
    Authentication Code (HMAC)
Not always correct.

    When you deploy an update to the application and want to invalidate   
    current sessions? When you’re updating sessions as data changes?  
    When you’re storing sessions?
The same way you would do with a session. You wouldn't clean your datastore you would change your secret.
Even with the exp claim if the user saves the token before they log out they can reuse it until it actually expires, you have to generate jtis and store them in a blacklist which is what the author of the article meant (you still have to have the concept of a session on the server to be totally sure).
Actually that is not a flaw at all. Expiration times should be low anyway by user facing tokens, sessions. Also why should you save a token before logout and reuse it? You could actually just re-login?

And still if the session won't get deleted when pressing logout you have the exact same problem.

Also there aren't many users pressing the logout Button anyway.

Edit: Btw. Sessions have flaws. Tokens have flaws, too. However the Flaws the author writes aren't actually problems / flaws it's just FUD.

Hi Merb, thanks for engaging with the article. I submitted it to get feedback like this as I would love to use jwt but it doesn't seem to have wide adoption or a whole lot of discussion and literature.

I think the idea of a user holding onto old expired tokens assumes that the user is a malicious party. A more useful example would be if the token were stolen, so the malicious party would not respect any attempts to expire the token before its expiration time is up.

Jwt is available for azure and Google as third party auth. It's all jws.
The same could easily happen to your Session's. Even easier since without some CORS mechanism your Session is gone stolen really fast.
Why can't you just change the secret on the server? It would invalidate all sessions.
Thanks for pointing that out. That's a good technique and it addresses a large concern about jwt that this article raised for me. I suppose it's still a problem with invalidating individual sessions but that's a smaller problem.