Search code examples
authenticationmobilearchitecturejwtrefresh-token

Mobile authentication approaches, JWTs and refresh tokens

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?

  • As mentioned in JWT (JSON Web Token) automatic prolongation of expiration Auth0 abandoned JWT for mobile in favor of random generated strings. What implementations are available in this case? Should I use this string as a never-ending id of the authenticated device and approve all API calls that have it attached?

  • 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?

Consulted resources

...and many more I'm not reporting as outside the scope of the question.

This question was originally posted here, https://softwareengineering.stackexchange.com/questions/430302/mobile-authentication-approaches-jwts-and-refresh-tokens/430315#430315

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

Solution

  • I don't think the requirement is well formed and it feels like it is based on a sweeping statement from product owners, without considering costs v benefits:

    • Gmail keeps me signed in forever and I want my app to work like that

    LARGE PROVIDERS

    The likes of Google often use bespoke solutions around analyzing user patterns, periodically getting 2 factor confirmation and other actions that would be very expensive for normal companies.

    OAUTH

    For normal software companies the problem has been solved via OAuth and the AppAuth pattern. Curity Guides provide a good starting point if you are not familiar with it:

    • Once coded you can use many authentication options with zero code changes in your UIs and APIs
    • User friendly password-less options such as WebAuthn are supported
    • You can even support advanced options such as App2App Logins if needed
    • Mobile code and the architecture remains simple in all cases

    USER CONSENT

    Note also that OAuth is built around users agreeing to the app using their details for a period of time. I often stop and think if I am abusing this - and what would be the impact if a user's device was stolen - not sure how relevant this is for your scenario ...

    MIDDLE GROUND

    For most companies I would recommend this type of option so that usability is good:

    • Start with a user friendly option such as 30 day refresh tokens
    • If you are using password logins, ensure that password autofill works - AppAuth will enable this

    TOKENS

    These are issued by an Authorization Server (AS) not developed by you. Think of this as a Docker Container that provides HTTPS endpoints - use a free or low-cost one.

    The motivation behind the Auth0 point you mentioned is explained well in this article. The mobile app just sends access tokens to APIs. There is no token issuing in your code and it remains simple.

    SUMMARY

    Prefer industry standard proven options with good cost v benefit results. OAuth is highly architectural though and there is a learning curve which your company needs to manage.