Topic starter
06/11/2026 6:36 pm
TL;DR: Stolen sessions can survive logout or idle expiry and keep Microsoft 365 email accessible at 79 organizations when session cookies, access tokens, and refresh tokens are not aligned, according to OLOID research. Timeout controls only work when the server ends the whole authentication state, not just the browser session.
Editorial analysis by NHI Mgmt Group, based on content published by OLOID: “Session Timeout Best Practices”.
Key questions
Q: What should teams do first when a session token is stolen?
A: Revoke the stolen session, invalidate the server-side session record, and force credential reissue by rotating the underlying refresh tokens or other long-lived secrets.
Q: Why can logout fail to end access in SSO environments?
A: Logout can end the application session but leave the identity provider session active, so a new login may be created automatically without fresh authentication.
Q: How do idle timeout and absolute timeout work together?
A: Idle timeout ends a session after a period of inactivity, while absolute timeout ends it after a fixed maximum lifetime regardless of use.
Practitioner guidance
- Set both idle and absolute timeouts Define a short inactivity window and a hard total lifetime for each application, with stricter values for privileged and regulated access.
- Revoke every token at logout Invalidate the server session, revoke refresh tokens, and ensure federated sign-out ends the identity provider session as well.
- Move enforcement to the server Reject expired sessions on every request and use client-side timers only for warnings, not enforcement.
Bottom line: Session timeout policy fails when one layer ends while another still accepts the user, because stolen or copied authentication state can keep working after the visible session closes.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:42 pm
Session timeout is only meaningful when every authentication state ends together. A browser session, an identity provider session, and a refresh token are separate control surfaces, so closing one does not guarantee the others are gone. The governance error is to treat logout as a single event when it is really a chain of expirations and revocations. Practitioners should review session design as one lifecycle, not three disconnected timers.
A question worth separating out:
Q: How should teams secure sessions on shared workstations?
A: Secure shared workstations by using short idle timeouts, automatic screen lock, and re-authentication before any privileged action. Presence-based locking can combine proximity signals, badge state, or local presence checks with the lock state, but it should never be the only control for protecting active sessions, cached credentials, or open admin tools.
👉 Read our full editorial: Session timeout best practices fail when tokens outlive sessions