If you scale up high enough, it does matter.
But beyond that, it is also about decoupling the server serving the content and the user database.
To give you an example, using a traditional session cookie model, whenever my server gets a request, it has to look up the associated session info, and then possibly join multiple tables to see if a specific user for that specific session is authorized to access that content.
There are going to be many joins involved. Even with good caching, it will still be a more complex operation.
Even if not computationally complex, it will be logically complex.
But when using a JWT, my server actually does not need ANY db access. It merely needs to verify the cryptographic validity of the included JWT header, which uses no IO. After that, it can safely trust any user metadata included in the JWT.
So, if a user has paid for access to all premium content after 2018, you would just include a field for that in your JWT payload. Done.
It depends of course on how your business data models work of course. But you can often put enough information in your JWT to cut out a lot of account processing logic.
> JWT is solving a non-problem for most people.
I think people are cargo culting JWTs.
You don't need any db access with signed cookies either. Just stash your data in a signed cookie and you're done. Should you need more than 4k for session data, maybe it's time to rethink about what should be stored in the session and what should be stored in the db.
I could have a server that doesn't have any access to the database at all, and it could still render content for the user.
And if the server is for something critical, like purchases, it can still use redis on each request to verify that a JWT is still valid.
> To give you an example, using a traditional session cookie model, whenever my server gets a request, it has to look up the associated session info, and then possibly join multiple tables
It does this on initial logon and then stores it in cache. You can think of a JWT as cache as well.
The point is, it only happens once for both.
JWT token does not require that.
Both solutions requires invalidation.
You want to try and move the goalpost that's on you, but your point about the joins is flawed. As is the rest of it, but I'm certainly not going to waste my time.
Solves some of the session problems..
Benefits:
Cookies - when set to http only + secure only are safer?
Drawbacks:
They're not cross-compatible No expiration baked in No not-before baked in Limited to hmac validation (no public key crypto options that I know of)
Unless you mean using a JWT as a cookie value. I guess that could work?
There are many, many implementations in use "in the wild". They are just signed payloads, so they can contain "expiration", "not-before" or whatever else you think isnt "baked-in". You can use any method of signing them, but would probably make sense to use a strategy that is considered secure :) No doubt the libs you mention can be extended trivially with this "missing" functionality.
Signed/encrypted cookies predate JWT - they even predate JSON...
Im not presuming that they are better/worse than JWT, just responding to the incorrect statement about cookie based sessions requiring server-side storage