Re:Ask HN: What's the current sentiment on JWT for stateless...
by xvector on Friday December 13, 2019 @08:12PM
(#21787116)
> A typical architecture might have a timestamp stored per user that specifies the earliest token creation date that’s valid for refresh.
Never worked with JWTs but still, can't believe I didn't think of this. It seems like a fairly elegant way to revoke things where your only stored state is a timestamp.
Re:Ask HN: What's the current sentiment on JWT for stateless...
by kelnos on Saturday December 14, 2019 @02:29AM
(#21788311)
> A typical architecture might have a timestamp stored per user that specifies the earliest token creation date that’s valid for refresh.
There's a race condition there, though. If you have a revocation event and set the timestamp, it's possible that an in-progress refresh might have a timestamp just slightly after your stored timestamp. Then you have a rogue JWT that can continue to be refreshed.
Clocks are sometimes not in sync with millisecond precision. Databases don't replicate instantly. Distributed systems just don't work that way.
Re:Ask HN: What's the current sentiment on JWT for stateless...
by JamesSwift on Saturday December 14, 2019 @09:42AM
(#21789703)
You could instead store a "generation", and increment on revocation events
A common validity period is around 1 hour, which is good enough that most users won’t need to refresh very many times per day.
Also: you don’t necessarily need to track tokens that aren’t refreshable. A typical architecture might have a timestamp stored per user that specifies the earliest token creation date that’s valid for refresh. That way you can invalidate all tokens without needing to ever store them; something you might need to do for password reset, for example.