10 Mobile Session-Management Edge Cases to Handle Before Release

Before release, check what happens when a token expires during a request or a half-filled form, when several requests refresh at once, when the app resumes after hours in the background, when the user is offline, when the server revokes a session, when logout is partial, when the user has several devices, when the device clock is wrong, when the app is reinstalled or restored, and when a deep link or notification arrives for a signed-out or different user. Each one either logs people out unexpectedly or shows data to the wrong person.

Login screens get careful design; the session that follows usually gets less. Most session bugs appear only under timing, network or lifecycle conditions that rarely happen on a developer's phone. This list is for mobile developers, backend developers and QA. For sign-in methods, token storage and account recovery, see mobile app authentication.

1. The access token expires in the middle of a request or a long form. The user fills in a form for ten minutes, taps submit and is sent to the login screen, losing everything. Handle a 401 by refreshing the token and retrying the request once, inside one shared networking layer, as described in mobile app API integration. Keep form state locally so a full re-login does not discard it.

2. Several requests try to refresh at the same time. A screen loads five resources, all get 401, and each starts its own refresh. With refresh token rotation, the first refresh invalidates the old refresh token, the second looks like token reuse, and a server with reuse detection revokes the whole session. Use a single-flight refresh: the first request refreshes, the others wait for its result. RFC 9700 requires refresh tokens for public clients to be sender-constrained or rotated, but leaves concurrency to implementers, so some teams also allow a short grace period on the server.

3. The app resumes after a long time in the background. The access token and perhaps the refresh token have expired, and the last screen is still showing, sometimes with private data. On resume, check the session before showing sensitive content or accepting actions. For sensitive apps, hide content in the app-switcher snapshot and consider requiring biometrics or a passcode after a period of inactivity.

4. The device is offline when the session expires. A network failure is not an authentication failure. Do not log users out because a refresh request timed out; keep them in an offline state, queue actions where the app supports it, and refresh when the connection returns. Give queued writes idempotency keys so replays do not create duplicates; see API idempotency patterns.

5. The server revokes the session. Password changes, account suspension, account deletion, sign-out from another device and security events should all revoke refresh tokens. The app should recognise the specific error, clear local data and explain what happened ("You were signed out because your password changed"), rather than showing a generic error or looping on refresh.

6. Logout leaves data behind. Deleting the token is not enough. Revoke the refresh token on the server, unregister the push token for that user, and clear the local database, caches, image caches, web view cookies, widget data and any files downloaded for that account. Test by logging out and logging in as a different user on the same device and looking for anything from the first account.

7. The user is signed in on several devices. Decide whether sessions are unlimited, limited or exclusive, and what happens to the oldest when a limit is reached. For sensitive apps, show a list of active devices with the ability to sign them out, and make sure that sign-out reaches the other devices on their next request.

8. The device clock is wrong. If the app decides whether a token has expired by comparing its expiry time with the device clock, a clock set minutes or hours wrong causes constant refreshes or use of expired tokens. Treat the server's response as the authority: refresh on 401, and if you check expiry locally, allow a margin or calculate an offset from server time.

9. Reinstall, backup restore and moving to a new phone. Whether stored credentials survive an uninstall, a backup restore or a device-to-device transfer depends on the platform, the storage used and the user's settings. Test each path on the OS versions you support rather than assuming. Android's backup guidance warns that if an app cannot use the data it restores, users lose their settings and progress without seeing an error, and recommends its Block Store API for credentials. Make sure a restored but unusable token leads to a clean sign-in, not a crash or a loop.

10. A deep link or notification arrives for a signed-out or different user. A notification about an order, or a link to a private screen, opens while the user is signed out, or signed in to a different account. Send the user through sign-in and then on to the original destination, and check that the content belongs to the current account before showing it. See mobile app deep linking and push notifications.

Session bugs are timing and lifecycle bugs, so they need deliberate tests: shorten token lifetimes in staging, force 401s, go offline, change the clock and reinstall. Centralise refresh in one place, distinguish network failures from authentication failures, and make logout and revocation complete. For broader security practices, see mobile app security.

IETF RFC 9700, Best Current Practice for OAuth 2.0 Security (refresh token protection). IETF RFC 8252, OAuth 2.0 for Native Apps. Android Developers, data backup overview and Block Store. Accessed 5 November 2026.