Thank you. I think you replied to the original post from May 2020 which was already answered. The subsequent question was about strategies to invalidate the tokens stored in the database, more concretely.
You answered that partially here:
When do you display the user’s list of sessions? Even then, you still have to wait for the user to take action (on his next login, which might be in a long time), while the compromised session is active.
So to reformulate my question, the theory is clear, we want the ability to invalidate a particular session that might have been potentially compromised; but in practice, are there some simple parameters (i.e. which won’t take me months to code) on which I can base myself to force the user to login again (thus by invalidating the session in the db)?
In other words, I currently do store the sessions in DB, but I do not make use of the advantage to store those, as long as I do not have an invalidation mechanism.
The „automated“ places to invalidate existing sessions could be on logout or when the password is reset. But also don‘t think you need automated ways to use the information. It might be just as useful to be able to react manually to compromised sessions e.g. when being informed by users.
IMHO it all depends upon your business use cases. For instance, you could allow the login but send the user an email or SMS to confirm a login from an unusual location (i.e. different country, state, etc.) and allow the user to either accept or reject via link. You could then automatically logout the invalid session if they reject it…so it’s semi-automated.
I’m not sure any fully automated mechanism will be user-friendly…except perhaps if they are on mobile and the IP address is from a vastly different location than where the token was issued, in which case you would delete the session and just have them authenticate again.
To do any of those, you’d need to also record the IP address when the user logs in and the session token is issued, so there would be some modifications to the generated code, but based upon your specific business logic…and you could defer that functionality to a later date with the generated model. However, if you didn’t do the session token at the start, it would be harder to implement later.
For my use case, I was proposing having a section in the account settings page to show active sessions and allow the user to label the known logins because we have both web and mobile (possibly multiple devices) for the same user that could be simultaneously active. …but that’s my business case. YMMV
