I'm aware of this trade-off.
It's fine, even desirable, for high security applications.
For other scenarios with lower security requirements like social networks, games etc... you could set the expiry to 24 hours so if the user uses the app at least once every day, then they will stay logged in perpetually.
The lower your security requirements, the further you can set the expiry time. If your security requirements are low, then you probably don't need the ability to revoke a token in 10 minutes anyway. It works out quite well. You can always have an isBanned flag/property on the user's account object for banning. So inside your access control logic, you check for the JWT and also check that isBanned is not true on the account record... OK, that means you need to look up the account record (which you would have to do anyway regardless of what session mechanism you use because it doesn't make sense to store an isBanned flag on a session object, but you really need that flag) JWT still saves you from managing session objects in a separate Redis instance or other.
If you compare the work and complexity involved in developing and maintaining the two solutions side-to-side, JWT is still much simpler overall for pretty much all scenarios. If you're talking about scenarios at scale, then JWT comes out even further in front. Session IDs require an entire extra infrastructure component; e.g. Redis.
> If you compare the work and complexity involved in developing and maintaining the two solutions side-to-side, JWT is still much simpler overall for pretty much all scenarios.
I still disagree, especially given the prevalence of session based solutions in pretty much every web framework out there.
Your post contains a couple of suggestions that are counter to just about every piece of advice I’ve ever read about JWTs (for example, increasing expiration times to a day). So, consider me thoroughly unconvinced.
And you’re not even considering the solution that some web frameworks (e.g. Rails) ship by default, which is to store the entire session object itself in a cookie, which was purpose built for that sort of thing. Then very little is required on the server.
In the rails example you gave, if they go so far as storing the entire session object in a cookie, I don't see why they wouldn't just use JWT as it's basically the same idea with an added signature to prove that it was generated by the server. Why would you invent something new which is just about as complex, has the same disadvantages and has fewer advantages?
Because the mechanism used is is simple and sufficient, and using JWTs would be more complex. Rails encrypts the cookie data so signatures are unnecessary.
Also, Rails has been doing this since 2007, three full years before the JWT spec was first published.
For other scenarios with lower security requirements like social networks, games etc... you could set the expiry to 24 hours so if the user uses the app at least once every day, then they will stay logged in perpetually.
The lower your security requirements, the further you can set the expiry time. If your security requirements are low, then you probably don't need the ability to revoke a token in 10 minutes anyway. It works out quite well. You can always have an isBanned flag/property on the user's account object for banning. So inside your access control logic, you check for the JWT and also check that isBanned is not true on the account record... OK, that means you need to look up the account record (which you would have to do anyway regardless of what session mechanism you use because it doesn't make sense to store an isBanned flag on a session object, but you really need that flag) JWT still saves you from managing session objects in a separate Redis instance or other.
If you compare the work and complexity involved in developing and maintaining the two solutions side-to-side, JWT is still much simpler overall for pretty much all scenarios. If you're talking about scenarios at scale, then JWT comes out even further in front. Session IDs require an entire extra infrastructure component; e.g. Redis.