3 ms·

You can track JWTs on the server, via a sessionId or whatever you wish, it just breaks the intended pattern. If you have to do a lookup on each request (necessa

You can track JWTs on the server, via a sessionId or whatever you wish, it just breaks the intended pattern. If you have to do a lookup on each request (necessary to invalidate the token imperatively) your JWT is no longer stateless which is a core tenet of the JWT approach. It'd be like building a React app and calling getElementById(id) to update DOM values. You _can_ do it but...

cogman10 4y ago
> breaks the intended pattern. Who's intended pattern? Where is this stated as being the "right" way to use JWTs? I'm seeing a lot of claims about the intent behind JWTs but frankly I think it's because people are skipping over having a fundamental understanding about WHAT JWTs are and instead are cargo culting on what they believe they should be.
- DavidSharff 4y ago
  My perspective is that I had recently realized that I didn't have a great justification for having used JWTs in my last two projects (and worried I had been part of a cargo cult myself). Truly. I can't see their value against a bearer token + session tracking on the server for most cases (e.g. it won't be a huge performance hit to do a lookup of some sort on each request). The two apps I'm referring to have a few thousand users who only make occasional requests. I think a lot of apps fall into this broad category and I don't see what extra value JWT is providing. Encoding user data is pretty convenient (though more opaque) but if you want to be able to ad-hoc invalidate them you need refresh tokens or a session list. Not only does that re-introduce needing to do a sort of lookup and server user tracking, the encoded data on the token is no longer a positive, since you bifurcated knowledge of the user (token + list), and all its data would be more discoverable by including it where you are now tracking sessions anyways. Help me out if I'm missing something. My mind is open.

cogman10 4y ago

> breaks the intended pattern. Who's intended pattern? Where is this stated as being the "right" way to use JWTs? I'm seeing a lot of claims about the intent behind JWTs but frankly I think it's because people are skipping over having a fundamental understanding about WHAT JWTs are and instead are cargo culting on what they believe they should be.

DavidSharff 4y ago
My perspective is that I had recently realized that I didn't have a great justification for having used JWTs in my last two projects (and worried I had been part of a cargo cult myself). Truly. I can't see their value against a bearer token + session tracking on the server for most cases (e.g. it won't be a huge performance hit to do a lookup of some sort on each request). The two apps I'm referring to have a few thousand users who only make occasional requests. I think a lot of apps fall into this broad category and I don't see what extra value JWT is providing. Encoding user data is pretty convenient (though more opaque) but if you want to be able to ad-hoc invalidate them you need refresh tokens or a session list. Not only does that re-introduce needing to do a sort of lookup and server user tracking, the encoded data on the token is no longer a positive, since you bifurcated knowledge of the user (token + list), and all its data would be more discoverable by including it where you are now tracking sessions anyways. Help me out if I'm missing something. My mind is open.