Skip to content

Technical research

Session security is a server-side lifecycle problem

Access tokens, refresh rotation, revocation, concurrent clients and recovery paths viewed as one state machine.

Published 2026-11-05 · By

Map the session as a state machine

Secure storage helps prevent accidental token exposure, but it does not fix an undefined session lifecycle. Model login, active use, token refresh, privilege change, account recovery, logout, global logout and administrative revocation as explicit transitions. Decide which server-side state each transition changes and when old credentials must stop working.

On mobile, the client may be backgrounded, offline or terminated during refresh. Network retries can race with a second device or app process. An apparently harmless retry policy can accidentally reactivate a revoked session or repeatedly rotate credentials.

Refresh and revocation must be atomic

Use short-lived access credentials appropriate to your threat model and make revocation semantics explicit. For refresh-token rotation, track token family, session ID, expiry and reuse detection; atomic single-use transitions help avoid replay. Decide what happens on simultaneous refresh: reject one safely, offer a bounded grace behavior or serialize requests. Do not create an indefinite acceptance window to hide race conditions.

Revoking a session should invalidate future refreshes and, where the risk requires it, terminate outstanding access through a server-side denylist, token version or equivalent check. Deleting a token from Keychain or Android storage alone cannot revoke a copy already held by an attacker.

Validation checklist

  • Old refresh credential replay is detected and handled consistently.
  • Logout invalidates server state, not only local storage.
  • Password reset and account recovery follow a documented session invalidation policy.
  • Concurrent mobile refresh attempts do not create multiple valid token descendants.

Secure storage, transport and recovery

Store mobile secrets using platform-appropriate protected storage and avoid copying them into analytics, crash logs, deep links or debug traces. Use TLS and validate server identity correctly. Protected storage reduces exposure but is not a replacement for backend checks; an attacker controlling the client can still invoke permitted APIs with captured or legitimately obtained tokens.

Account recovery is especially sensitive because it may bypass normal device or factor possession. Require fresh authorization for critical changes and avoid letting an old session approve its own privilege elevation.

Design the tests around failure

Simulate backgrounding during refresh, offline replay, multiple devices, parallel refresh, clock skew, expired access token, revoked refresh token and stolen token reuse. Exercise both the client-visible outcome and the backend token-family record. Measure false sign-outs and error rates without weakening security to avoid them.

Primary references

Engineering practices and threat-model choices, not product certification, a guarantee against compromise or a customer penetration-test result.

Follow a related topic