Is there a way (maybe via browser extensions) to make sessions forcefully expire after a while, even if the server side is set for longer durations?

e.g. you authenticate to example.com and it starts a session that is valid for 5 hours. You work on this website for 10 minutes. Then you start a new tab and work on other things.

What I would want then is for this session to start timing out and maybe after 10 minutes do a forceful logoff

  • 1
    A client can't force the server to handle a session a particular way. It can log off, which should close the session (if it's designed that way).
    – schroeder
    Commented Apr 23 at 21:29
  • maybe see this one: chromewebstore.google.com/detail/advanced-auto-logout/… Commented Apr 26 at 20:37
  • @browsermator yes I did look at that as part of my research before asking the question. My interest was more from a policy compliance view. Like there are acceptable use policies on using certain software and websites which employee agrees to, but that is contingent upon being followed, and people make mistakes and forget. So this was really just a fanciful whim of maybe we can force the browser to click the logout button when they walk away or forget or something. Just a box ticking exercise really, but I accept that it isn't that feasible and move on :-P
    – Aethalides
    Commented May 21 at 20:04

1 Answer 1


Conceptually, what you're asking for doesn't really make sense, because the client is not, can not be, and never should try to be trustworthy about whether a session is valid. The client is inherently untrustworthy; "never trust the client" is one of the fundamental rules of browser (and most other client-server architecture) security.

However, there are various ways to make a "best effort" attempt to end the session early. You can't rely on these, but they do limit the risk.

  1. The only way to reliably do this is by controlling the server. If you control the server, the obvious thing is to make the sessions time out automatically after inactivity. Simply refresh the session lifetime (potentially by e.g. re-issuing a JWT, if you want to avoid server-side state) any time the session is active, and if it's inactive for a while, it automatically ends. You usually want to have a hard expiry on there too (which could be stored server-side, or in an extra field on a JWT) so that if an attacker steals the session token they can't just keep refreshing it forever. If you want to make the idle timeout longer than 10 minutes, I'd recommend having a refresh token and a shorter-lived JWT so that the user can take an actually-meaningful "log out" action (the session might still be active for a few minutes, but not for the full e.g. 15 minutes since last action).
  2. You can also store the session token in a cookie, which is set to expire at a certain time. This is not reliable - an attacker who steals that token will simply keep using it past the time that the cookie expires, and the expiration itself won't happen if e.g. the browser is not running (an attacker could extract the cookie from the browser's cookie file at rest). These limitations will apply to all future examples as well, which is why the only way to reliably end sessions prematurely is to have the server do it.
  3. If you control the client-side script but not the server logic, you can add a timeout function that automatically calls the "log out" endpoint, instructing the server to end the session. This is still trusting the client - an attacker who steals the session token will try to prevent the browser from making this logout call through any number of means, such as closing the tab or blocking the request - but it's an option. Unlike cookie expiration, it requires an action on the part of the browser script and won't happen if the page is no longer active for any reason; however, it works on things that aren't cookies. Note that this (and the next two options) are fairly ineffectual unless calling the logout endpoint actually does something (to cause the server to terminate the session) beyond simply removing the token from the client.
  4. If you don't control the site at all, you can use a browser extension to inject a client script into the site, which performs the action in #3. This is subject to exactly the same limitations as #3, plus the problem that the user isn't even automatically protected; they have to manually install the extension (or, I suppose, and admin of their workplace or whatever installs it for them). At this point, it's a real stretch to argue that the effort spent is worthwhile, but you could do it (it wouldn't even be a complicated script or require a dedicated extension; you could add it as a user script through something like Tampermonkey).
  5. While we're discussing options that only work if the user takes some positive action, the user could simply log themselves out when idle. Obviously this is more error-prone, but the actual security difference isn't that great unless your users routinely leave their computer unlocked where another person could access it, in which case you probably have bigger problems.
  6. As #5, but instead the user manually clears browsing data, or runs the site in a private/incognito window and closes it when they no longer actively need it. This is equivalent to having the cookie expire automatically (aside from not happening automatically); the server might still accept the token for far longer if it is somehow stolen prior to being deleted from the browser.

As a side note, it's a really bad user experience to have sites automatically log you out after a short period. That's especially true if the site itself sometimes requires the user to spend a while doing something, like reading a long document or collecting some information from outside the site or answering a lot of questions that don't individually refresh the session expiry. Make sure you actually need to do this before implementing it.

You must log in to answer this question.

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