2 ms·
This is something I’ve gotten into fights with coworkers over when I proposed doing a similar thing. It was a weird circular argument and I’m very curious if so
by spyspy 5y ago
This is something I’ve gotten into fights with coworkers over when I proposed doing a similar thing. It was a weird circular argument and I’m very curious if someone here has a better opinion than, “JWTs can’t store state because they’re stateless!”
- ryan-allen 5y agoWithout offering an alternative solution I'm not sure what your co-workers are trying to accomplish. The article doesn't offer much of a solution either. The only valid criticism I see in these threads are unless you are tracking a revoke list then the JWT is still valid on a user initiated logout until it expires. If you're going to roll your own tokens you're probably going to end up some form of tamper proof encryption even if you're storing additional session information on the backend. Without specific comparison to other styles of session management this is just all FUD to me.
- dirkt 5y agoThe whole point of a JWT is that it is stateless, and the information is (cryptographically signed) in the client. The advantages and disadvantages of JWT both derive from that. If you want a session, just use an opaque session cookie. Then all information is safely handled in the server. While it's certainly technically possible to use a JWT like a session cookie (or store session information in it), what you then get is a solution that combines the disadvantages of both approaches: All the complexity of making "visible" client-handled information safe, with the additional overhead of also having it in the server, while you loose the advantages of a JWT in integrating third-party services. So, either use one, or use the other, depending on your requirements. Don't combine them.