I'm implementing a web login system and am confused about how to think about when authenticated sessions (not just browser sessions) should be expired.

There seem to be 2 factors:

  • absolute lifetime of a session;
  • idle time.

Idle time makes sense to me.

Having an absolute lifetime implies a session should be expired even if the user is actively using the site at the time. That would be a poor user experience; and also doesn't seem to be what happens in practice.

So how is absolute lifetime generally handled?

It seems to me one option could be to discard the current session and start a new session each time an authenticated user makes a request. Then the session lifetime and the idle time are effectively one and the same thing, and an active user won't be logged out while clicking around the site. But as far as I can tell the OWASP guides don't talk about this. Is it a sensible approach?

There also seems to be something called session "renewal" but I don't understand it – is it simply changing a session's identifier without affecting its expiration?

  • I have been trying to find the best practices for this as well and been unable to. My best guess is. If the session is short (designed to only cover a single sitting) there is not much we can do other than use some method to not lose customer progress. For longer multi day sessions I think we can use some idle timer to ask for login credentials when we near the absolute timeout when the user has not done anything for hours or days,
    – Jonathon
    Commented Feb 18 at 18:00

1 Answer 1


as far as I can tell the OWASP guides don't talk about this

OWASP addresses session timeout and explains the risk:

The Session timeout defines an action window time for a user, this window represents the time in which an attacker can try to steal and use a existing user session…

If timeout depends on idle duration only, and such token is stolen, then the attacker can first establish refresh process by sending requests regularly to have a valid token at any time. In the meanwhile the attacker can analyze the API better, construct a desired bad request, then executed it. The attacker will have unlimited time for such work.

OWASP suggests following:

  • Set session timeout to the minimal value possible depending on the context of the application.
  • Avoid “infinite” session timeout.

Then, if the token is stolen, the attacker will have limited time to use it.

Too long validity increases the risk of successful attacks. Too short validity makes user experience worse. Only you can decide what risk is acceptable and thus what timeout is acceptable.

Some other thoughts about timeout you can find also here.

How can you implement it? Before you implement your own solution from scratch, consider using some existing solutions. For instance, there are many implementations of Open ID Connect. Implementing your own solution should address many questions. For instance, do you want your application to handle both access to resources and authentication or do you want it to be two separate applications? If you have such kind of questions, ask them as separate posts, because a single post should address a single question.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .