Session expiry recovery
Review expiry at the write boundary, not just the login screen
The important questions are what survives, what may already have happened and who is allowed to continue after sign-in.
In this article
Separate the states in the design
Locate authentication, draft and command state. Ask which one is authoritative for access, which preserves unfinished input and which identifies an attempted business action.
Confirm that server-side expiry is enforced independently of any client timer. Review idle, absolute and other relevant policy boundaries without assuming they are interchangeable.
Inspect the draft's sensitivity and storage policy. Credentials should not be copied into draft storage as a shortcut for resumption.
Challenge the recovery sequence
Expire access before a command is authorised, then repeat with a successful server write whose response is lost. The implementation should distinguish rejection from uncertainty.
Verify that recovery uses the original command identity where required. A generic retry interceptor must not create a new consequential action after every sign-in.
Change the underlying record before restoration. The user should review or resolve a stale version rather than automatically applying old assumptions.
Change the identity that returns
Sign in as another account or organisation and inspect both draft access and cached page data. The application must not restore old work under the new identity's authority.
Remove the original user's permission during expiry and verify current authorisation. Authentication success alone should not revive the removed permission.
Review return destinations and navigation history. Reject untrusted redirects and prevent Back or refresh from trapping the user in a loop.
Test operability and evidence
Use keyboard and representative assistive technology with any warning or reauthentication dialog. Check focus, retained fields and the message shown after return.
Inspect logs for useful correlation without session secrets. Support should be able to identify whether a command succeeded without asking the user for a token or recreating the request.
Approve the flow only after demonstrating restored drafts, recovered receipts and deliberate denials under the appropriate contexts. A successful login demo tests only the middle of that sequence.
Primary sources
OWASP: session managementW3C WAI: timing adjustableReferences checked 11 September 2026.