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.
LostKobrakai
drl123
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
1