Throw a session ID in the JWT and do the same thing.
JWT has a freeform payload that can literally be anything you want. Nothing about it prevents you from using a pattern like this.
JWT has a freeform payload that can literally be anything you want. Nothing about it prevents you from using a pattern like this.
A simple session ID can be (and often was) forged to grant access to things end users shouldn't have. Put the session id in the JWT and now an attacker can't easily change the session they are associated with.
There are enough CVEs on this specific topic that I tend to disagree. I've been around on the internet long enough to witness a HUGE number of session hijacking attacks. [1]
> Using JWT doesn't substantially make this easier for you and operationally you are going to have to invest in significant key management infrastructure.
IDK about making it easier, but rather using JWTs for this makes it harder to get wrong.
> If you don't need the stateless nature of JWT you should just not use them.
Agreed. Use them when they make sense and not when they don't. I'm not arguing that JWTs are panacea. They are neither good nor bad, just a tool.
[1] https://owasp.org/www-community/attacks/Session_hijacking_at...
JWTs don't make it any harder to hijack sessions, in fact, they often make it easier.
Session sniffing and man in the middle attacks don't discriminate between JWT and cookies/session IDs. Nowadays they are very hard to achieve with the vast majority of the web operating over HTTPS with optional HSTS.
Cookies containing the session ID can be marked as HTTP only, unlike JWTs which are often stored in localStorage, which makes them vulnerable to extraction via XSS vulnerabilities.
> using JWTs for this makes it harder to get wrong
Any popular web framework these days should provide secure built-in functions to generate and validate cryptographically secure signed cookies containing the session ID.
JWT libraries have had critical vulnerabilities in the past, such as allowing usage of the badly designed "alg: none" feature of the JWT specification.
https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
Whereas generating new session ids will always need fresh entropy.
If the signing of the JWT wasn’t deterministic, then it would be hard to verify.
It'd be like building a React app and calling getElementById(id) to update DOM values. You _can_ do it but...
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.
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.