4 ms·
What about a stolen user password and an actor, who already uses your token? Can the targeted user kick him out by resetting his / her password?
by drinchev 8y ago
What about a stolen user password and an actor, who already uses your token? Can the targeted user kick him out by resetting his / her password?
- nbevans 8y agoSure why not? Each user account has a counter or timestamp on it in the user registry. If the JWT token in the request passes crypto validation but it has an older counter/timestamp than held in the user registry then it is deemed invalid and the user must re-authenticate. This is still a horizontally scalable design.
- gravypod 8y agoThen you are back to statefulness if you need to check this magic "count" every request.
- nbevans 8y agoYou can horizontally scale counters with CRDTs, specifically the G-Counter. Whereas it is harder to scale a (usually) opaque blob of application state a.k.a. session state.
- aaaaaaaaaab 8y agoThis “user registry” of yours sounds an awful lot like a traditional session table in a central DB. Could you elaborate a bit on that in terms of horizontal scalability please?
- nbevans 8y agoUser registry can scaled however you want it to be. It is simply the service that manages user accounts, passwords, permissions, and of course issues the JWT tokens. Equally it can be a horizontally scaled micro service.
- csours 8y agoNo, but that's 3 systems away upstream anyway - thus the 30 minute timeout.