3 ms·
Actually creating a JWT token is not stateless, but at least your architecture is not centralized. If your auth server goes down, that’s a problem no matter wha
by jchw 7y ago
Actually creating a JWT token is not stateless, but at least your architecture is not centralized. If your auth server goes down, that’s a problem no matter what.
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.
- xvector 7y ago> 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.
- deleted 7y ago[deleted]
- kelnos 7y ago> 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.
- JamesSwift 7y agoYou could instead store a "generation", and increment on revocation events