Session test cases, for the token that still works

Almost every session test is run through the interface, and the interface is exactly where expiry always appears to work. The cookie is cleared, the router redirects to sign in, and the screen is convincing. None of that says anything about whether the server invalidated the session. The only test that answers the question is to capture the token before signing out and then send it directly to a protected endpoint. If it succeeds, sign out is a client side illusion, and anyone holding a copy of that token keeps access for as long as it remains valid. The refresh token deserves the same treatment, because one that outlives sign out reconstructs the entire session on demand.

Timeouts need two limits rather than one. An idle timeout refreshed by activity has no upper bound, so a session can live for weeks as long as someone keeps using it, which is precisely what an attacker with a stolen token will do. An absolute lifetime caps it. The complementary defect is counting automated traffic as activity: a page that polls for notifications or auto saves a draft will hold a session open indefinitely while the user is genuinely absent, and this is the single most common reason an idle timeout does not work in practice.

The user experience half is not a nicety, it is why the control gets weakened. A session that expires and discards a completed form teaches people to avoid the product or to demand a longer timeout, which undoes the security benefit. Preserving entered values through re-authentication, returning to the interrupted page, and specifically not replaying the interrupted request when it was destructive are all testable and all usually absent. Multi tab behaviour belongs here too, since one tab continuing to look signed in after another expired produces failures the user cannot explain.

Finally, revocation is the part users actually rely on. After losing a device or suspecting a compromise, the controls that matter are ending one named session, ending all of them, and having a password change invalidate the others. Each needs to take effect immediately and each needs to cover refresh tokens, otherwise the session reappears at the next refresh. A concurrent session limit needs a concurrency case of its own, because two simultaneous sign ins against a limit of two will let a third through if the count is read and then written.