How long is too long for a user session? and who actually decides that in your team?
most apps have a session timeout. almost nobody knows why it's set to whatever number it's set to.
ask around and you'll usually get one of three answers. 'that's just the default.' 'someone picked it a while ago and we never changed it.' or 'i think security asked for it but i'm not sure why.'
session length is one of those decisions that sits in a weird gap between product, engineering, and security. product wants users to stay logged in forever because re-authentication kills conversion. security wants short sessions because long ones are a risk. engineering sets whatever makes the tests pass.
nobody owns it, so nothing gets revisited.
and the right answer is actually different for every action. viewing a dashboard is not the same risk as transferring money or changing a payout account. a session that's fine for browsing is too stale for a sensitive operation. but most products apply one timeout to everything and call it done.
the more interesting question isn't how long. it's how do you make the session length fit the action, not just the user.
curious how teams are actually making this decision. is there a policy, a person, or is it just whatever got shipped and never touched again?
Replies
the "fit the action, not just the user" framing is the right one, and the way we ended up implementing it was to stop thinking of it as one session timeout and instead have a base session that's long-lived for read-only stuff, plus a short-lived step-up token that gets minted only when someone hits a sensitive action. so browsing a dashboard rides on the long session, but changing a payout account silently requires a fresh step-up check even if the base session is still valid. it sounds like more infrastructure than it is, most auth providers already support some flavor of step-up or reauth-on-scope. the harder part honestly wasn't the tech, it was getting product and security to actually agree on which actions count as "sensitive" - that list needs an owner too, not just the timeout number.
MonoCloud for Startups
@galdayan the list needing an owner is so real 😄 that's the part that always gets skipped. everyone nods at the concept, nobody wants to maintain it as the product evolves.
and yes the step-up approach is exactly right. base session for the low risk stuff, fresh check when it actually matters. sounds like more work than it is and makes the whole thing way easier to reason about.
I think every destructive action a user can take (especially around account permissions and payment info) needs an extra layer of security. For my clients (Saas) I implemented this system, but the destructive actions inside their account can still ride the long session. For example if a user wants to delete an event or something like that in their account, it's fine, we can't police what they do with their own data. But once they want to change their billing or manage API keys, password authentication kicks in again