1

Context

I'm developing togther with my dev team a mobile app in a client-server architecture, since there will be a webclient too, allowing some users (admins) to perform certain operations from the browser.

The REST Api currently authenticates users by returning access and refresh tokens in form of JWTs. Both local (username/password) and OAuth2.0 (only Google at the moment) flows are available, as I provide the user with these two different options for authenticating.

Problem

The flows that follow are working just fine when the API is called from the webclient, but now that we've started developing the mobile app a big question arised: **how do we keep the user authenticated on the mobile app even after the refresh token expires?**

All the famous apps out there do not prompt the user to authenticate let's say weekly or worst daily, but still I'm sure their authentication practices are (almost) flawless.

Tried paths

I've read many blog posts and articles, together with some StackExchange Q&As as reported below, but the right way to approach authentication and access persistence on mobile is still unclear.
  • Should I create a specific endpoint (or many) to provide non-expiring tokens only when the User-Agent header tells the API is being called by a mobile device?

  • In the OAuth case, should I perform (I don't know how) silent calls to the OAuth provider to get back a new idToken and then request new tokens to my own API with it?

  • In the local case, should I keep user credentials stored locally? If so, how do I do that securely?

Some diagrams

These are the flows we've currently implemented, working as espected when the API is consumed by a webclient.

Local Local flow


OAuth2.0 OAuth2.0 with Google provider flow

2
  • Can you elaborate how you are using the access and refresh tokens that were received after the login? Jul 16, 2021 at 8:27
  • I store them in the browser in the form of httpOnly cookies, on mobile I was thinking of attaching them as a bearer token in the auth header thus storing them with RN's AsyncStorage. Jul 16, 2021 at 9:19

1 Answer 1

3

how do we keep the user authenticated on the mobile app even after the refresh token expires? All the famous apps out there do not prompt the user to authenticate let's say weekly or worst daily [...]

This use case is the sole purpose of refresh tokens. So set the expiry to match how long you want the user to be able to stay signed in without being prompted to sign in again.

It's quite normal for refresh tokens to be valid indefinitely.

This should work the same for browsers and the app, and both signin methods (unless you want to treat them differently for a reason you didn't mention).

In the OAuth case, should I perform (I don't know how) silent calls to the OAuth provider to get back a new idToken and then request new tokens to my own API with it?

It's sufficient to refresh the access token without consulting the OAuth provider. Since you're issuing refresh tokens, I assume there's a /refresh type of endpoint where the client can send the refresh token and be issued a new access token. The user's expired access token should be enough to validate the provided refresh token.

Conceptually, refreshing the access token using the refresh token is extending the validity of the original sign-in. We can't get another proper sign-in without involving the user, so automating additional sign-ins doesn't help.

1
  • Thanks for the comprehensive answer, I'm going to implement an indefinetely valid refresh token for both web and mobile clients. Jul 19, 2021 at 8:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.