Search code examples
mobileoauth-2.0access-tokenopenid-connectidentityserver3

How do mobile apps gain long-lived access to their API's?


Our company is building a mobile app (iOS) which needs to talk to our API, which is secured by OpenIdConnect/OAuth2, using IdentityServer.

My question is, most apps i've used these days ask for the user to login/register once, then never again.

Assuming they are accessing their API's using OAuth2 tokens, how do they achieve this?

OAuth supports offline_access via "refresh" tokens, which allow getting new tokens without the user logging in again. However, they also have an expiry - so given the following scenario:

  1. User creates account, gets access token/refresh token. Access token expires in 1 hour, refresh token in 2 hours.
  2. User is using the app, app gets new access/refresh token in background
  3. User closes app
  4. User comes back the next day

At this point, both the access and refresh token are expired. How do they get a new one, without prompting the user to enter credentials again?

I understanding OpenIdConnect has the concept of identity tokens, and as long as this is active at the server, new access tokens can be fetched without prompting the user again.

So, i can only think of two ways apps do this:

  1. They have background services that run when the app is closed, that keeps getting new access/refresh tokens. Is this possible?
  2. On app start, if the access/refresh tokens are expired but the identity token (session) is still active, do a silent trip to the auth server (hidden web view?) which will automatically get a new set of tokens.

2 seems possible, but this would only work in the browser-based OAuth flows (implicit, authorization code) where there is SSO/cookies involved.

For apps that have a native login (U/P in app), they are most likely using the Resource Owner Password Credentials flow, which doesn't support SSO (no browser, no cookies). So how would they get new tokens, unless they are storing a reversible username/password in the client app itself, then passing them to the Auth Server again to get new tokens?

What am i missing?

Thanks in advance.


Solution

  • The apps typically use long-lived refresh tokens that don't expire in 30 mins as you suggest but may live for many weeks/months until the user is forced to login again. Making the lifetime of the refresh token the same as the access token defeats the purpose as the refresh token should be the token that can be used to get a new access token when the old one expires. Refresh tokens typically outlive the user authentication session at the provider.