Or put another way - is there a process for deciding how long a user's authenticated session should last?
I don't agree with Edgarator that you should ask the user, especially not at log in.
It is all very nice and well to allow the user to change it, but don't ask them to make a decision that is totally unrelated to what they want to achieve with your application.
Decide a sensible default for yourself - possibly using the criteria Edgarator shows in his answer. Make it short-ish. And DO provide option to change it longer in some settings dialog.
It would be difficult to find a standard time to measure how often to expire a session in a mobile device.
So, what I would do is:
- Define what's my user
- How sensitive the information I'm dealing with is
1. To define the user
You might want to think around the lines of:
- Is he security conscious?
- Does he need quick and easy access to the application? (perhaps older people would get annoyed by having to type a password with symbols, uppercase and lowercase with at least 8 characters every time).
- Would making it difficult to login a burden for adoption or my application would be needed regardles of how difficult is to log in?
If this doesn't matter perhaps you could add different session expiry settings at the beginning and learn (by tracking it on your server) from your user how often your standard user like the session to be expired. For example:
2. To define how sensitive the information is:
Pretty much all legal implications here:
- Think about what would happen if your information gets lost?
- Should I take care of my user (beyond providing the means for a secure connection), or
- Should I let the user deal with the consequences of device mishandling?
- Mobile Applications such as Facebook don't care much about expiring the session on mobile devices due to the fact that it would stop people from using it A LOT.
- Mobile Applications like GMail would expire the session every once in a while, so that you don't get annoyed by it if it happens every blue moon, but still if someone breaks into your phone, they wont have unlimited access to do eavesdropping on your phone.
- Mobile Applications such as Online Banks would expire the session after closing the application, as unwanted transactions could be made, and that could affect the bank itself. Also, on this, a security aware user is most likely to start saying that the app is no good due to the fact that it lack security.
Once. A User should be asked to login to a mobile application on their own personal device one time per device/install so as to access data pertaining to their own account. Anything more is implying that their mobile device is not personal and/or the communication channel is insecure (e.g. MITM attacks).
Though there is room for considering (worrying about and putting controls in place to mitigate the risk of):
- rooted devices (whether intentionally or via a vulnerability),
- stolen devices,
- sharing of the mobile phone.
For those cases, other controls exist and they may be sufficient and/or better implemented than controls in your own app. E.g. lockscreen, remote phone wipe, etc for a stolen device. Family controls for sharing devices. And for rooted devices, well the breach of personal or sensitive data in your app/system is probably minor in terms of what can be done across the device in that scenario.
So ultimately it should come down to a risk assessment of your system, the data it works with, the actions it can make, and a decision-maker's willingness to sign off on identified risks.