Re:Anatomy of a JWT
by candiddevmike on Tuesday March 01, 2022 @08:28PM
(#30522513)
I think most folks would run away screaming from a codebase that did and did not check session data. Hopefully any company that does this has a lot of money set aside for bug bounties.
Every sizable system I’ve ever seen does it to some extent. It’s super common for static content with no security implications to not bother with a live check, or a system with high load but no major security implications (read only content for instance) to not do synchronous checks.
Especially if we’re talking 5-10 second session timeouts, it’s rarely even a theoretical concern and dramatically reduces load.
A ‘stateless’ JWT with a unique session identifier allows you to check state WHEN YOU WANT, but not when you don’t. So you can use it statelessly to your hearts content, or statefully when you need.
And the short time stamp definitely doesn’t mean an attacker can use it indefinitely, it means they can only use it for a short time before they have to check in with the backend that generates tokens to get a new one - which that backend would know that ‘logout’ or whatever had happened, and not generate one for it.
It sets a maximum period of time where old tokens can be used in a stateless fashion without ‘checking in’, while also not requiring a full synchronous check of a database on every usage of every token.