Sure. Just pushing back on the ‘you’re going to hit the database anyway’ argument. Having some kind of mechanism for eliminating obviously bogus requests is a good idea. Some sort of signed, expiring token is probably a good idea for that. Rolling your own expiry/signing mechanism is probably a bad idea. Correctly validated JWTs are an option (among many) for solving that problem.
Include an expiry time in the encrypted part. The encryption, and the fact the token decrypts invalidly if not encrypted with the correct key, acts like a discount JWT.
Encrypted session tokens with embedded expiry will serve the needs of 99% of applications/services.
This is not a huge surface area. I don't know why this keeps coming up, but, while a silly default, is incredibly straightforward to not configure / remove / test for.
JWTs are definitely a much larger surface area than simpler encrypted sessions storage and most people don’t need that.
I cited this as one example of that surface area that led to serious vulnerabilities. Most people don’t need multiple ways to encrypt their data, and certainly not a ‘no encryption’ option. Each added option adds more ways to mess things up.
Encrypted session cookies are a proven solution, widely used, and easy to implement yourself using only core libraries (http, crypto, JSON) without introducing security flaws IFF you are an experienced programmer and don’t deviate from the norm.
JWTs are complex. Too complex to implement yourself, so you need to introduce dependencies. Dependencies are usually huge, and each line of code introduces risk (even if that line is for a configuration you don’t use!). Using JWTs at all is far more risky, even if you are an experienced programmer.
If JWTs provides immense benefits over session tokens for your use case, that risk might be worth it. However, for most web apps, session tokens are good enough.
