[9dev]

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]

This also means an attacker can be running around with a compromised token for up to a half hour before they're stopped.

[9dev]

If that is unacceptable for the business case, it's probably clear JWTs for sessions are unfit for the particular task?

[frankthedog]

Is it acceptable for any business to allow accounts to be compromised for a half hour?

[9dev]

I'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.