An abstract discussion on the security of long-term app logins

[dantman]

I’d like to start a discussion about security of long-term app logins.

To my understanding the standard/state of the art for the long-lived logins that apps use to keep a user from needing to re-login regularly, is to store a refresh token that is valid for months or longer in the app.

This token being an opaque/bearer token that is sent over the wire when it’s used and stored in a location that the app can retrieve the whole token from. Which to me feel like the same issues why we usually want auth/session tokens to have a short life.

It occurs to me that the correct/secure way to do refresh tokens that last for a long duration would be to use public key cryptography and use platform native APIs to store keys in hardware backed keystores where available (WebCrypto’s non-extractable keys, Android’s hardware-backed keystore, keys in iOS’ Secure Enclave). So the app is not able to retrieve the contents of the private key.

However while this seems like the most secure way to implement long-term logins, I have not been able to find any reference to this being common in-practice or libraries that implement it.

So, am I off base with this train of thought? Or is the security of auth solutions used in-practice lacking? Or can anyone find libraries implementing this type of refresh key security, or at least companies that have deployed it.

[James.Morrison]

Good morning and thank you for starting a conversation here in the Auth0 Community!

Let me see if I can have a senior member join in on this conversation here to provide value. Thanks!

[nicolas_sabena]

Hi @dantman

To my understanding the standard/state of the art for the long-lived logins that apps use to keep a user from needing to re-login regularly, is to store a refresh token that is valid for months or longer in the app.

Yes, that’s the OAuth2 usual flow for native applications. Regular web applications usually rely on session cookies for this, unless there’s a need to do some work when the user is not present.

It occurs to me that the correct/secure way to do refresh tokens that last for a long duration would be to use public key cryptography and use platform native APIs to store keys in hardware backed keystores where available (WebCrypto’s non-extractable keys, Android’s hardware-backed keystore, keys in iOS’ Secure Enclave). So the app is not able to retrieve the contents of the private key.

I’m not sure I’m following here… What would exactly be the purpose of this? To keep the tokens from the application? Or to secure the token in transit?

Among other recommendations, the OAUth2 Authorization Framework mention this in relation to the security of the tokens:

Access token credentials (as well as any confidential access token attributes) MUST be kept confidential in transit and storage, and only shared among the authorization server, the resource servers the access token is valid for, and the client to whom the access token is issued. Access token credentials MUST only be transmitted using TLS as described in Section 1.6 with server authentication as defined by [RFC2818].

Refresh tokens MUST be kept confidential in transit and storage, and shared only among the authorization server and the client to whom the refresh tokens were issued. The authorization server MUST maintain the binding between a refresh token and the client to whom it was issued. Refresh tokens MUST only be transmitted using TLS as described in Section 1.6 with server authentication as defined by [RFC2818].

The security in transit is ensured by using TLS.
In terms of token storage, there are not platform-specific details for each platform but developers are expected to use each platform’s key store mechanism. Our Android quickstart, for example, uses the SecureCredentialsManager class to securely store the tokens. It can be configured to require a PIN, password, or fingerprint confirmation from the user to access the stored tokens. Similar functionality is provided by the Credentials class in the iOS SDKs.

Hopefully I’m somehow addressing your question with this response

OAuth2 Authorization Framework

Oauth2 for Native apps