Home / Knowledge hub / Sliding session
Knowledge hub
Sliding session
A session whose expiry is pushed back each time the user is active.
What it means
A sliding session is one whose expiry moves forward each time the user does something. If the idle limit is 30 minutes, every request resets the clock to 30 minutes from now. The session ends only when the user stops for the whole period.
This is the behaviour most people expect. A person actively working is not thrown out in the middle of a task, while an abandoned laptop signs itself out. It is the idle timeout in action, as opposed to an absolute timeout that counts from login.
Why it matters
The risk is that a session never has to end. Anyone who keeps it alive, a script that pings the app every few minutes or a stolen token used steadily, can hold it for days or weeks. A limit that was meant to protect users then protects nothing.
It also affects what a thief can do with a leaked token. If the stolen session slides, a pause by the real user does not cut the attacker off, as their activity renews it. Auditors look for both limits for this reason, and enterprise questionnaires often ask directly.
How it shows up
Pair the sliding idle limit with an absolute limit counted from login, after which the user must sign in again. Do the same for renewable tokens: a refresh token that extends itself endlessly is a sliding session without an end. See session timeout.
The mistakes: no absolute cap, extending on background requests such as polling which the user did not make, extending on a failed or unauthenticated request, and renewing without issuing a fresh identifier. Sensitive actions should ask for a fresh sign-in whatever the session age. Test by keeping a session busy past the stated absolute limit.
Questions people ask
Sliding session, answered
What is the difference between sliding and fixed expiry?
With sliding expiry each activity extends the session. With fixed or absolute expiry, the session ends at a set time after login, whatever the user does.
Most secure designs combine both.
Does background polling keep a session alive?
It can, if every request resets the timer. A page that checks for updates every minute then keeps a session open indefinitely, even if the user left.
Decide which requests count as user activity and renew only on those.
How long should the absolute limit be?
It depends on risk. Hours for sensitive apps, perhaps a day or more for low-risk tools. The limit is a ceiling that forces a fresh sign-in whether the user is active or not.
Choose it with the data in mind.
Is a sliding session less secure?
Not by itself. It improves usability and still enforces an idle limit. It only becomes a weakness when no absolute limit exists, or when automated activity keeps renewing it.
The design matters more than the label.
How do we test it?
Sign in, keep making requests for longer than the absolute limit, and see whether the server ever forces a new sign-in. Then stop and check the idle limit works too.
A session that outlives the absolute limit is a finding.
Sources
Where this comes from
Related
Terms that sit next to this one
Session timeout
The point at which an idle or old session stops working and sign-in is required again.
Session management
How your app creates, tracks, renews and ends a signed-in visit.
Refresh token
A long-lived token used to get new short-lived access tokens without signing in again.
Remember me
A long-lived login option, and the extra risk it carries if its token is stolen.
Session hijacking
Stealing the token that tells your application a browser is logged in.
Can a session stay alive forever?
We keep sessions active past their stated limits and report whether the server ever asks for a fresh sign-in, with the requests that show it. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.