Mobile authentication approaches, JWTs and refresh tokens

Question

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

---

OAuth2.0

Answer 1

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.