Sign-in and Sessions
An app holds a session on a device, which is a different security problem from a browser session.
Where to find it
Architect Panel → Mobile Apps:
- Mobile Canvas — the app, its screens and its settings
- App Builds & Releases — building and submitting
- Mobile Devices — the devices that have installed it
Architect Panel → Configuration:
- Site Settings — the Mobile Apps option group
Admin Panel → User Administration:
- User Groups — what the user can reach once signed in
The settings
- Sign-in method — the platform’s own, or through an identity provider.
- Biometric unlock — whether the app can be unlocked with a fingerprint or face.
- Session lifetime in minutes.
- Refresh lifetime in days.
A session is short-lived; a refresh token keeps the user signed in across sessions until it expires. The two together decide how often somebody has to type a password.
The trade
A long refresh lifetime means people rarely sign in, which is what they want. It also means a lost device stays signed in for that long, unless the device is revoked.
Somewhere around a fortnight to a month suits most workforce apps, with biometric unlock covering the gap.
Biometric unlock is the right compromise
It lets you keep a short session lifetime without making people type a password all day. The app locks quickly and unlocks with a fingerprint, which is both more secure and less annoying than a long session.
The installation can also require it, so it is not left to each user.
Sessions are per device
Each is recorded against the device that holds it, with its issue time, last use, issuing address and expiry. So a session can be revoked individually — which is what you do when somebody loses a phone.
Limit devices per user
An installation-level maximum. Without one, a user accumulates sessions on every device they have ever installed the app on, including ones they no longer have.
Five is a sensible default and generous for most workforces.
Idle devices expire
A device not seen for a set period is expired automatically. That is what stops the device list becoming a list of every phone anybody has ever owned, each holding a valid session.
Have a lost-device procedure
Written down, before you need it: revoke the device, revoke its sessions, and know who can do it out of hours. A phone is lost at the weekend, not on a Tuesday morning.
Test what expiry feels like
Let a session expire and use the app. A user hitting an expired session mid-task should be asked to sign in and returned to what they were doing — not dropped at the home screen having lost their work.
Worked example
A workforce app uses a fifteen-minute session with biometric unlock required and a fourteen-day refresh, limited to three devices per user, with idle devices expiring after six months. A lost phone is revoked by the service desk, which has a written procedure and out-of-hours cover.
Recommendations
- Short sessions plus biometric unlock, not long sessions.
- Limit devices per user.
- Write the lost-device procedure before you need it.
- Test an expiry mid-task.