4 ms·
I keep a counter in the JWT to at least mostly get around this issue. When processing a request, the counter is checked for the user, which isn't a big deal si
by low_key 10y ago
I keep a counter in the JWT to at least mostly get around this issue. When processing a request, the counter is checked for the user, which isn't a big deal since all of the requests already require looking up the user. A counter increment invalidates all of that user's existing tokens.
If a user changes their password, their roles change, etc, then the counter gets incremented so all tokens issued up to that point won't be valid anymore.
- snikch 10y agoYep ^ This is what I often do too. Simple, but effective.
- ForHackernews 10y agoCan you explain this a little bit more? You keep a counter on the user object in the DB? What is the JWT buying you if you still have to hit the DB on every request?
- mstade 10y agoPresumably you can keep counters like these on the server edges, and just push new values out to servers whenever things change, as opposed to query a DB every time. This wouldn't invalidate individual tokens however, but all tokens that have that counter value. It'd also mean there's a window where tokens can still be used while servers are being updated with the new value(s). These are just some random and half-baked thoughts, I have no idea what OP does, but there are options to limit hitting backing DBs anyway.
- njknsdf 10y agoYou can store the user info in the JWT so you don't need to hit the database to get user info every time. I usually just store an id in each issued token and store/remove it from redis or memory as needed for invalidating it.
- ekryski 10y agoYou have to be careful that you are not leaking sensitive info though, as the JWT payload is meant to be visible on the client as well.
- ekryski 10y agoThat's pretty smart. Effectively versioning your issued tokens. Way easier than maintaining a blacklist.