Mobile app best practices, variable session length?

[kszafran]

Hello! I have a two-part question regarding the usage of Kratos with mobile applications. In my use case, there will be various kinds of client applications, including browser-based applications and mobile apps.

What are the best practices when it comes to authentication with mobile apps? I'm thinking of having either persistent authentication (so that users log in only the first time they open the app) or long sessions, say 7 or 30 days (longer than browser clients). The obvious approach would be to store the Kratos session tokens in iOS Keychain.

However, that's where my second question comes in -- is it possible to have variable session lifetimes based on some condition/request parameter/etc.? I believe that is not the case, which means that if I wanted to have 7 day session on mobile apps, I'd also have them in browser clients (which could maybe work if I implement e.g. idle timeouts for browser clients). Another approach could be to manage mobile app sessions outside of Kratos.

To sum up:

1. What is the suggested way to use Kratos with mobile apps? (Assuming that we don't want user to provide their credentials all the time.)
2. If/how could variable lifetime be achieved?

Looking at the login flow, I'm not sure where we could even add a session lifetime parameter in a way that would not depend on user input 🤔. My best guess would be to allow session lifetime configuration via hooks and make the decision based on the user agent header...

[kszafran]

I think I just found a relevant thread: #1603 But I'm still not clear what the best practice would be when it comes to mobile apps. In that thread the following two suggestions were made:

1. Strict TLS enforcement with certificate pinning for HTTPS connections
2. Storing credentials in the OS credentials chain

Regarding 1: While using HTTPS is a no-brainer, certificate pinning seems to be discouraged: https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning While I understand that a mobile app would not necessarily need to rely on the deprecated HPKP headers, and it's possible to just roll out a new app version if a certificate is revoked, it would still be disruptive to users. Or perhaps I misunderstood what was meant by certificate pinning?

Regarding 2: That could work. My only problem with this approach is that it's discouraged by OWASP:

Persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device;
Ideally, mobile applications should utilize a device-specific authentication token that can be revoked within the mobile application by the user. This will ensure that the app can mitigate unauthorized access from a stolen/lost device;
(https://owasp.org/www-project-mobile-top-10/2016-risks/m4-insecure-authentication)

The "authentication token" suggested by OWASP sounds a lot like the Kratos session token. But if we don't want to keep Kratos sessions open for very long periods of time, then it would have to be some other session-like token managed outside of Kratos that grants access to our system. Alternatively, the "authentication token" could be yet another authentication method that could be used instead of a password to open a Kratos session.

[vinckr]

Hello @kszafran,
Thanks for this interesting thread and for compiling all this information!
I think you are right about certificate pinning, there are probably different opinions on this, but IMO it can disrupt the users and also can be a security issue.

We have a blogpost on adding Auth to a react native app as well as one going into implementing OAuth2.0 flows in mobile Apps
In the post, we use SecureStore to store the credentials, so basically the second option: Storing the tokens in the device's keychain.
I think the OWASP concern is legit - that the app can't mitigate access when the device is stolen, but as soon as we have more fine-grained session management implemented this is no longer a problem: #655. You can just delete the session from the admin end e.g. if the device is flagged as stolen.

[kszafran]

Thanks for those article links, I'll check them out.

I was thinking if there would be any benefit to storing a hashed password instead of cleartext on the device, and using something like password_hash as an alternative authentication method. Or even just some UUID. Maybe if the hash/UUID was registered with Kratos, then we could revoke it when the device is compromised without having to change the user's password itself 🤔. Maybe I'm overthinking it, but it feels like it would be more secure to store some kind of value unique to the device compared to the password itself. Password reuse is still common.

Something like:

1. user logs in for the first time with their password/OIDC/TOTP/etc.
2. Kratos registers some unique value, possibly derived from the username+password+device fingerprint
3. that value is then stored securely on the device and can be used to silently re-authenticate the user when needed

I'd prefer not to invent my own security protocol, though. Perhaps there's already something similar out there? Or is storing user credentials the standard way of going about this? I'm completely unfamiliar with mobile app development, which is why I keep asking such questions.

Also, the "value" in 3. sounds a lot like a session token. Perhaps if we could just have different session lifetimes for different clients somehow...

[vinckr]

Hey @kszafran
Ory now supports Social sign-in for native and mobile apps 🎉

[kszafran]

Thanks for the heads up! We'll try it out once a new Kratos version is released. Now I'm just waiting for a proper invite flow (#3264 (comment)) and I believe all our use cases should be covered 😄.