> where devices are lost or stolen, or data is accidentally leaked > someone just threw out an old PC that they haven't used in years and the disk isn't encryp

> where devices are lost or stolen, or data is accidentally leaked > someone just threw out an old PC that they haven't used in years and the disk isn't encrypted. These are scenarios where I think expiration doesn't help at all. I assume your reaction is not just "oh well, the compromised sessions on that device will expire in 70-ish days so we can just ignore it" but instead you immediately consider everything on the device compromised and kill all sessions, rotate all account passwords, etc. If it takes you a day or two to notice this event happened, expiration doesn't help: long expiration hasn't happened yet, and with a short expiration, you still don't know and can't assume it protected anything. In fact, the safe thing is to assume the session was accessed within minutes of the incident. > For my service I ended up doing something in between. Sessions last for 14 days, but they are automatically renewed indefinitely. This is a pretty rational approach, but of course the time frame depends on your users and how they user your system. Auth0 has a good rationale behind their approach[1]: > You can configure session limits with up to 100 days of inactivity (idle timeout) and up to one year in total duration (absolute timeout). > The motivation behind the 100-day idle timeout cap is to cover one quarter plus a few days, which provides wiggle room for people who log in to do end-of-quarter reports. [1] https://auth0.com/blog/balance-user-experience-and-security-to-retain-customers/ https://auth0.com/blog/balance-user-experience-and-security-...