3 ms·
Rather than just "JWT is awesome..." wouldn't it be more sensible and responsible to caveat this with some of the drawbacks? I read this article recently (http
by br3w5 10y ago
Rather than just "JWT is awesome..." wouldn't it be more sensible and responsible to caveat this with some of the drawbacks?
I read this article recently (http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/ http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...) that proposes not to use it for sessions but instead for the use cases listed at the end of the article. Follow-up article here http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...
Also this https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/ https://auth0.com/blog/2015/03/31/critical-vulnerabilities-i...
- k__ 10y agoWhy not using one key per user? Then I would just have to invalidate this one user and not all of them.
- rahkiin 10y agoYou don't know who the user is until you verified the integrity of the JWT. Verifiying the integrity requires the secret. Your solution adds the dependency: the secret requires the user. It is cyclic, unsolvable without breaking a constraint. You could assume the username is correct, then get the secret, validate. But that sounds like something breakable.