Why mobile sessions are different from web sessions
Web applications typically use server-side sessions with cookie-based identifiers. Mobile apps operate differently: they use JWT or opaque access tokens stored locally on the device, communicate over APIs rather than browsers, survive app backgrounding and device restarts, and the user expects to stay "logged in" across sessions without re-entering credentials constantly.
This creates a tension between security and usability. Users do not want to log in with full credentials every time they open their banking app. But maintaining persistent access increases the attack window if the device is compromised, stolen, or the token is extracted. The solution is layered session management with biometric re-authentication.
Token storage: the foundation
Where you store session tokens determines your baseline security. This is non-negotiable for financial applications:
- Android: Store access and refresh tokens in Android Keystore-backed encrypted storage. Use
EncryptedSharedPreferenceswith a master key generated in the Keystore. Never use plain SharedPreferences, SQLite, or files on internal storage. - iOS: Store tokens in the Keychain with
kSecAttrAccessibleWhenUnlockedThisDeviceOnlyto prevent backup extraction and cross-device migration. SetkSecAccessControlBiometryCurrentSetto require biometric auth before the token can be read. - Cross-platform: Use
flutter_secure_storage(Flutter) orreact-native-keychain(React Native)—both delegate to platform keystores. Never store tokens inAsyncStorageorshared_preferences.
For a deeper comparison of platform-specific storage options, see our iOS vs Android security guide.
Session timeout and backgrounding
Mobile apps have a unique lifecycle challenge: users constantly switch between apps. When your banking app goes to the background, the session should not remain fully active indefinitely.
Inactivity timeout
Track the timestamp of the last user interaction. If the user has been inactive for more than the configured timeout (we recommend 5 minutes for banking apps), require re-authentication before allowing any further operations. This timeout should be enforced both client-side (for UX responsiveness) and server-side (the token should have a matching expiry or the server should track last activity).
Background timeout
When the app moves to the background (onPause/applicationDidEnterBackground), start a background timer. If the app is not foregrounded within 2-3 minutes, clear the in-memory session state and require biometric re-authentication when the user returns. This protects against scenarios where a user leaves the app open and someone else picks up the device.
Screen obscuring
When the app enters the background, immediately obscure the screen content in the app switcher/recent apps view. On Android, set FLAG_SECURE on sensitive activities. On iOS, add an overlay view in applicationWillResignActive. This prevents sensitive data (account balances, transaction details) from being visible in the app switcher screenshots.
Sessions that never expire
In multiple assessments of Nigerian fintech apps, we found refresh tokens with no expiry or with expiry periods exceeding 90 days. One lending platform issued refresh tokens that never expired and were never rotated. An attacker who obtained a token once—through device theft, backup extraction, or a compromised development machine—would have permanent access to the account until the user explicitly changed their password.
Biometric re-authentication
Biometric re-auth is the bridge between security and usability. Instead of asking users to re-enter full credentials, require a fingerprint or face scan to resume a session or authorise sensitive operations.
The implementation must be cryptographically backed, not a boolean check. The correct pattern:
- Generate a key pair in the hardware Keystore/Keychain tied to biometric authentication.
- When the user authenticates with biometrics, use the Keystore key to sign a challenge from the server or decrypt the locally stored refresh token.
- The server verifies the signature. If valid, the session continues.
- If biometrics fail, fall back to full credential authentication (PIN, password).
Do not implement biometric auth as: "if biometric check returns true, proceed." This is trivially bypassed with Frida on a rooted device. The biometric must gate access to a cryptographic operation that cannot be performed without the hardware keystore. See the authentication security section for how we test this.
Device binding
Device binding ties a session to a specific physical device, preventing token theft from being useful on another device. Implement it by generating a device-specific identifier during initial authentication (a key pair in the hardware Keystore/Keychain), registering the public key with your server, and requiring a device signature on every API request or at session renewal.
If a token appears from a device whose signature does not match the registered device, reject the request and alert the account holder. This is particularly important for Nigerian fintech apps where device theft is a real risk—the stolen token is useless without the bound device's hardware key.
Concurrent session handling
Should a user be logged in on multiple devices simultaneously? For mobile banking, our recommendation is strict: one active mobile session per account.
When the user authenticates on a new device, the server should: invalidate all existing sessions for that account, send a push notification to previously active devices ("Your account was accessed from a new device"), and log the event for fraud monitoring. If the user did not initiate the new login, this notification gives them immediate visibility to report compromise.
For lower-risk operations (balance checking, transaction history), you might allow limited concurrent sessions. But for sensitive operations (transfers, PIN changes, beneficiary management), enforce single-session access.
Is your session management protecting users or giving attackers persistence? Our mobile pentest includes session hijacking, token extraction, and biometric bypass testing.
Test Your Session SecurityRefresh token rotation
Refresh tokens are the most valuable target for an attacker because they grant long-lived access. Implement rotation: every time a refresh token is used to obtain a new access token, issue a new refresh token and invalidate the old one.
If an attacker steals and uses the refresh token, the legitimate user's next refresh attempt will present the now-invalidated token. This mismatch is a strong signal of compromise. When detected, your server should: invalidate the entire refresh token family (all tokens issued from the same initial authentication), force re-authentication, and flag the account for review.
Without rotation, a stolen refresh token provides silent, persistent access that can last for the entire token lifetime—potentially months. Rotation transforms a stolen token from a permanent backdoor into a detectable, single-use credential. Combine rotation with reasonable refresh token lifetimes (7-14 days for banking apps) and the rate limiting on token refresh endpoints.
Server-side session controls
Every session control must be enforced server-side. Client-side timeouts improve UX but provide zero security—the client can be modified. Your server should: track the last activity timestamp per session, enforce absolute session lifetimes (force re-authentication after a maximum period regardless of activity), maintain a session revocation list for immediate invalidation, and log all session events for CBN audit requirements.
Related reading
Blog: iOS vs Android Security · Mobile App Pentest Checklist · Biometric Spoofing in KYC
Guides: Mobile App Pentest Nigeria · Fintech Security Checklist · CBN Compliance Security
Services: Authentication Security · Penetration Testing · API Security
Frequently asked questions
{faq.q}
{faq.a}