Hacker News new | ask | show | jobs
by DavidSharff 1365 days ago
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...
1 comments
cogman10 1365 days 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.

link
DavidSharff 1365 days 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.

link