For low-friction-to-change services that can be a death-sentence, though. If I have to log in when opening my electric scooter rental app, I close it and open another one and probably won't use the other one until strictly necessary.

My company has the same kind of "problem". A logged out customer might be a lost one. So we try extremely hard to never have to log out people. So when rewriting the app, the store couldn't be touched. When changing authentication provider the old tokens still had to work and be exchanged for a looong time etc.

you just have to keep thundering herd of logins in mind though.

While the application components can handle the load, sometimes the authentication system may not do well when everyone tries to login at the same time

Slack learnt that the hard way recently

One assume, since this was days in the making, that the GitHub security team had operations spool up extra auth tier capacity before booting all sessions.

aws does this every 24 hours for a normal setup and that's pita. They just don't care what their users are doing. Yes I was on middle of something and suddenly saw that I had to log into their web console again. w???

For our service I chose to end sessions at 4 AM local time, but have them last at least 8 hours.

This means:

* sessions last between 8 and 24+8 hours

* if you log in before 20:00, your session ends that night, if you log in after 20:00 it'll last one more day

* since this is a B2B application users are unlikely to use the application during session expiry

* it's possible to calculate the expiry time during log in and it doesn't require tracking session activity

This approach should have similar security properties as a 24h logout, while minimizing the disruption users experience.

Is that why gitlab.com always logs me out?

Apple's App Store Connect do this everyday lol