Mobile App Session Management: Refresh Tokens, Logout and Devices

Users expect a mobile app to remember them. Nobody wants to type a password or wait for an OTP every time they open an app. At the same time, a phone can be lost, stolen, shared with family or compromised by a malicious app. Session management is the engineering discipline that balances both: staying signed in for a long time while keeping the ability to cut access off quickly.

Many teams spend weeks on the login screen and very little time on what happens after it. This guide covers the parts that matter once a user is signed in: tokens, storage, refresh, logout and multiple devices.

The Basic Model: Access Tokens and Refresh Tokens

Most modern mobile apps use two kinds of credentials after login:

• Access token: sent with every API request. It is short-lived, so if it leaks, the damage window is small.
• Refresh token: used only to obtain new access tokens. It lives longer and is stored more carefully, and it is sent only to the authentication endpoint.

When the access token expires, the app silently calls the refresh endpoint and receives a new one. The user never notices. When the refresh token expires or is revoked, the user must sign in again.

JWT or opaque tokens?

Access tokens are often JSON Web Tokens because your API can verify their signature without a database query. Refresh tokens are usually better as opaque random strings stored server-side, because you need to look them up, track them and revoke them. Mixing the two approaches in this way is common and sensible.

Secure Storage on the Device

Where you keep tokens matters as much as how you issue them.

• iOS: use the Keychain with an appropriate accessibility setting, for example one that makes items available only after the device is unlocked.
• Android: use the Android Keystore, usually through EncryptedSharedPreferences or a well-maintained wrapper.
• React Native and Flutter: use libraries that wrap these native stores rather than generic async storage.

Also make sure tokens never appear in logs, crash reports or analytics events. It is surprisingly common for a debug log line to print a full authorization header into a crash reporting tool. The OWASP MASVS mobile security checklist is a helpful reference for storage and logging rules.

Refresh Token Rotation and Reuse Detection

With rotation, every refresh request returns a brand new refresh token and invalidates the previous one. The server keeps track of each "family" of tokens that started from one login.

If an old refresh token is ever presented again, something is wrong: either an attacker copied it or the app has a bug. The safe response is to revoke the entire family and force a fresh login on that device. This turns a silent token theft into a visible, contained event.

Handling the race condition

Rotation introduces a classic mobile bug. If several API calls fail at the same moment because the access token expired, each may try to refresh simultaneously. The first succeeds, the others present an already-used token and trigger reuse detection, logging the user out unexpectedly. The fix is a single-flight refresh in the app: one refresh request runs, all other requests wait for it and retry with the new token. Some teams also allow a very short grace period on the server for the previous token.

A Real-World Example: A Field Sales App on Shared Devices

Consider a distributor whose sales representatives use company-owned Android phones to take orders from retailers. Phones get swapped between staff, sometimes lost, and representatives occasionally leave the company. Early on, the app stored a long-lived token in plain preferences and had no server-side session list. When a phone went missing, the only option was to reset the user's password, which did not even invalidate the token already on the device.

A sturdier design for this kind of app could include:

• Short-lived access tokens and rotating refresh tokens stored in the Android Keystore.
• A sessions table recording device model, app version, last seen time and approximate location of last use.
• An admin screen where a manager can revoke all sessions for a departing employee in one click.
• A "sign out other devices" option in the app for representatives themselves.
• An idle timeout that requires a PIN or biometric unlock after a period of inactivity, without a full re-login.

With this approach, a lost phone becomes a two-minute admin task instead of a security incident.

Step-by-Step: Implementing Session Management

1. Define your session policy. Decide access token lifetime, refresh token lifetime, idle timeout and whether sensitive actions (payments, changing email) require recent re-authentication. Write these down before writing code.
2. Create a server-side sessions store. Each login creates a session record with user ID, device information, created time, last used time and a hashed refresh token. Never store refresh tokens in plain text.
3. Issue tokens at login. Return a short-lived access token and a refresh token tied to the session record.
4. Store tokens securely on device. Use Keychain or Keystore based storage, and keep the access token in memory where practical.
5. Build an HTTP interceptor. Attach the access token to requests, detect authentication failures, run a single-flight refresh and retry the original request once.
6. Implement rotation and reuse detection. On every refresh, issue a new refresh token, mark the old one used and revoke the family if a used token appears again.
7. Add logout that actually logs out. Logout should call the server to revoke the session, then clear local storage. Clearing only the device leaves a valid refresh token on the server.
8. Expose a device list. Show active sessions in account settings with device name and last activity, and allow users to revoke any of them.
9. Revoke sessions on sensitive events. Password changes, account recovery and suspicious activity should revoke other sessions automatically.
10. Test the edge cases. Test airplane mode, app killed during refresh, clock changes on the device, app updates and reinstall. These are where session bugs hide.

Passwordless Login and Biometrics

Session management works alongside, not instead of, your login method. Passkeys and OTP reduce password risk at sign-in, while biometrics make it easy to re-confirm identity during a long session. If you are modernising sign-in too, see our guide to passkeys and passwordless login for web and mobile apps.

A common and user-friendly pattern is: sign in once with a passkey or OTP, keep the session alive with rotating refresh tokens, and ask for a biometric unlock when the app returns from the background after a set period or before a payment.

Monitoring Sessions in Production

Session logic is easy to break with an innocent change, such as a new API gateway setting or an app update that changes how storage is migrated. Treat it as something to monitor, not just something to build once.

• Track unexpected logouts. Log an analytics event whenever the app forces a sign-in, with the reason: refresh token expired, revoked, reuse detected or refresh failed. A spike after a release is an early warning.
• Watch refresh endpoint errors. A rising error rate on the refresh endpoint usually means a bug or a backend dependency problem, and users will feel it as random sign-outs.
• Alert on reuse detection. Occasional reuse events can come from bugs, but a cluster for one account or one app version deserves investigation.
• Clean up old sessions. Run a scheduled job that deletes expired or long-inactive sessions, so the device list stays accurate and the table does not grow forever.

These signals help your team catch session problems before they show up as one-star reviews saying "the app keeps logging me out."

Key Benefits of Getting Sessions Right

• Fewer forced logins: users stay signed in smoothly, which supports retention and daily usage.
• Contained incidents: stolen tokens expire quickly or are detected through reuse, limiting damage.
• User control: a visible device list builds trust and lets people protect their own accounts.
• Admin control: businesses can cut off access for lost devices or departing staff immediately.
• Audit readiness: a sessions table gives you a clear record when customers or auditors ask who accessed what.

Common Mistakes to Avoid

• Using a single long-lived token with no way to revoke it.
• Storing tokens in plain shared preferences or async storage.
• Logout that only clears the device and leaves the server session active.
• Parallel refresh calls that log users out randomly.
• Printing authorization headers in debug logs that ship to production.

How Mavani Solution Builds This

On the apps we deliver, session handling is part of the core architecture rather than an afterthought, and we test it on real devices under poor network conditions. If you are planning a new app or tightening security on an existing one, our mobile app development team can review your current approach and design a session model that fits your users.

Conclusion

Good session management is invisible when it works. Users stay signed in, the app feels fast, and when something goes wrong, such as a lost phone or a departing employee, access can be cut off in seconds. Use short-lived access tokens, rotating refresh tokens stored in platform secure storage, a server-side session list and a logout that truly revokes. Those few decisions protect both your users and your business.

Frequently Asked Questions

How long should an access token last in a mobile app?

Access tokens are usually kept short-lived, often somewhere between a few minutes and an hour, so a stolen token has limited value. Longer-lived refresh tokens keep the user signed in by obtaining new access tokens in the background.

Where should a mobile app store authentication tokens?

Use the platform's secure storage: the Keychain on iOS and the Android Keystore, typically through EncryptedSharedPreferences or a library that wraps it. Never store tokens in plain preferences, local files or logs.

What is refresh token rotation?

Refresh token rotation means the server issues a new refresh token every time the old one is used and invalidates the old one. If an attacker replays a used token, the server can detect reuse and revoke the whole session family.

How can users log out of other devices remotely?

Store each session server-side with a device name, last activity and status. Show the list in the app's security settings and let users revoke any session. Revoking deletes or invalidates its refresh token so that device must sign in again.

Are JWTs required for mobile app authentication?

No. JWTs are a common format for access tokens because APIs can verify them without a database lookup, but opaque tokens checked against a session store work well too. What matters more is short lifetimes, secure storage and the ability to revoke sessions.