Best Way to handle Authorization tokens on mobile apps

Question

in our organization we have our own OpenId server (Identity Server) that we use to authenticate people into our applications, let me explain how we currently handle our web clients.

so we have an API that handles the authentication of users, the user calls an endpoint then they are redirected to the user's login page (on the identity server) and once they log in they are redirected back to the API (Authorization workflow + PKCE), the API sets an encrypted cookie on the user's browser that contains the access and refresh tokens, now the user is authenticated and any request they send has to go through the authentication API, which checks the cookie and attaches it to the request header then sends it to the desired upstream. As you can see, we don't trust the clients, which is why we store the access tokens in an encrypted cookie that only the authentication API can access.

okay so now how can we implement this on mobile devices? same as before we make an authentication API but instead of storing access tokens in an encrypted cookie we have to hand over the authorization tokens to the app, and the app will store and manage the authorization tokens, or we can keep them on the server and send back an id for the user, every time they send a request the send that id and the authentication API will handle managing the tokens.

but is that secure? what if someone stole the user's phone and got their hands on the user's authorization tokens? I've read that we should keep the tokens short-lived for better security but still, it is possible to do some harm during the token's short life. plus if they get their hands on the fresh token they will have access till the refresh token expires.

Are my concerns valid? what is the best way to handle this process on phones? the app is a very sensitive app with very sensitive data.

Thank you.

Answer 1

... what if someone stole the user's phone and got their hands on the user's authorization tokens?

In general, there is always a trade-off between usability (which also impacts acceptability by the user) and security. Which trade-off is acceptable depends on the risks, i.e. how likely a threat scenario is and what damage can be done.

If the attacker has stolen the users device and basically now owns it, then you need to add something which is not on the users device, like requiring another user authentication if the IP address from where your service was accessed has changed. Or make sure that the user has recently authenticated against your local application, like using fingerprint, face id or a pin.

If the attacker only gets short time access then make sure that they cannot extract the token in the first place or that the token is bound to the device and thus useless without the device. The latter can be achieved by also requiring device-specific authentication, for example by using mTLS with a client certificate where the private key is protected by some kind of secure element on the device (see RFC 8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens.