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.

  • Both android and iOS have keystore APIs to encrypt app secrets at rest. You can use that. When the user opens the app, the app will request keystore to decrypt them.
    – defalt
    Feb 18, 2023 at 9:52
  • yes, but is it not possible to change an app back to its source code and run the application to get back the stored keys?
    – MoTahir
    Feb 18, 2023 at 12:15
  • Keys are not embedded into the source code. They are stored by the TEE chip in the device. See, Secure way to hold private keys in the Android app and Protecting keys with the Secure Enclave.
    – defalt
    Feb 18, 2023 at 12:38
  • I see, but then can't the application source code be used with the stolen device to extract the tokens?
    – MoTahir
    Feb 18, 2023 at 14:18
  • Like how? Without root access on the stolen device, apps' internal data is not accessible.
    – defalt
    Feb 18, 2023 at 14:32

1 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .