5 ms·
Issue tokens that have a reasonably short TTL - say, half an hour - and let clients use their refresh token to obtain a new token after that. On refresh request
by 9dev 4y ago
Issue tokens that have a reasonably short TTL - say, half an hour - and let clients use their refresh token to obtain a new token after that. On refresh requests, ask the database whether the refresh token has been invalidated, if it is, return 403 (bonus points for checking the expiration date first and delete expired and invalidated tokens from the invalid-list).
This reduces the necessary database roundtrips, while still supporting a logout flow.
- ryeguy 4y agoThis also means an attacker can be running around with a compromised token for up to a half hour before they're stopped.
- 9dev 4y agoIf that is unacceptable for the business case, it's probably clear JWTs for sessions are unfit for the particular task?
- frankthedog 4y agoIs it acceptable for any business to allow accounts to be compromised for a half hour?
- 9dev 4y agoI'd actually argue that yes, that is acceptable for more businesses than you might think. We're talking about a session staying usable after logging out for 30 minutes in the worst case. For this to be exploitable, you'll have to jump several other hoops, like accessing localStorage of another application, for example.