Mobile Session Architecture: Beyond Tokens
Mobile authentication is often reduced to a simple flow: authenticate the user, issue an access token and refresh token, then attach the access token to API requests.
In production, a token is only one credential within a broader session lifecycle. The complete architecture must also handle device association, refresh concurrency, revocation, risk changes, recovery, and authorization updates.
The Token Is Not the Session
A server-managed session can track:
- The user and application instance
- Refresh-token family and generation
- Device-bound public key
- Idle and absolute expiry
- Authentication strength
- Risk and revocation status
This state allows the backend to control future refreshes and apply current security policy. However, previously issued self-contained access tokens may remain usable until expiry unless the receiving API checks live session or revocation state.
Refresh Rotation Requires Atomicity
In a rotation-based design, every successful refresh consumes the presented refresh token and returns a new generation.
The transition must be atomic. Otherwise, concurrent requests can create multiple valid refresh-token branches.
The mobile client should also coordinate refresh requests. When several API calls fail because an access token has expired, only one request should perform the refresh while the remaining requests wait for its result.
An invalidated refresh token appearing again may indicate credential replay, but it can also result from a retry, delayed response, or concurrency race. The backend therefore needs an explicit reuse policy instead of automatically treating every duplicate as confirmed theft.
Device Binding Should Use Keys
A device identifier stored inside a token provides correlation, not cryptographic binding.
A stronger approach binds the token or session to an application-generated public key. Protected requests then include proof that the caller can use the corresponding private key.
This reduces stolen-token misuse only when the relevant APIs consistently validate:
- The proof signature
- The bound public key
- The request method and destination
- Proof freshness
- The access-token hash
- Replay controls
Protected storage reduces key-extraction risk, but it does not make the mobile client completely trusted.
Logout Requires Server-Side Revocation
Deleting local credentials signs the user out of the legitimate application, but it does not invalidate copied credentials.
A complete logout flow should revoke the targeted server-side session, prevent future refreshes, clear local credentials, remove sensitive cached data, and deactivate account-specific background activity.
“Logout from this device” and “logout from all devices” should remain separate operations.
Risk Should Affect Session Policy
Risk-based expiry is more than shortening a token lifetime.
The system can combine:
- Access-token lifetime
- Refresh inactivity timeout
- Absolute session expiry
- Device or key trust
- Transaction sensitivity
- Recent or stronger authentication
- Session revocation
A weak signal, such as a network change, may only increase monitoring. A stronger combination of signals may require reauthentication or block sensitive operations.
Read the Full Architecture
The complete article covers token boundaries, refresh-token rotation, key-based binding, logout propagation, risk-based expiry, concurrency failures, offline behaviour, and deployment trade-offs.
Read the full Medium article.
Top comments (0)