How to handle JWT refresh token in a mobile app environment

Question

I am implementing JWT inside a client mobile app with a separate back-end server, and I am looking for an optimum way to use refresh tokens without too much server calls and while keeping a good user experience.

I am new to implementing such a mechanism, and I am confused about many things, so what I am really looking for is a solid conceptual solution to secure the user access to the app, and keep him at the same time logged in indefinitely.

Any correction or suggestion would be most welcome:

• Why refresh tokens anyway?

  Using a JWT access token alone might compromise the user security: If an attacker holds the access token, he might run feature requests whenever he wants. Even when applying an expiry date to the access token, if the server issues a new access token whenever the old one expires, the attacker will receive this new access token using his old one, and keep accessing the user features.

  Refresh tokens stop the attacker once the user regains access to his account using his login/password: When the user uses the app and the server detects that his refresh token is invalid, he will be logged out and a new refresh token and access token are issued after he's logged in with his credentials. The attacker won't be able then to use the old tokens.

  My first question would be:

  I. Regardless of how the attacker gets hold of the tokens from the user environment, would he be able to use them indefinitely as long as the user is still inactive and isn't logged in again with his credentials to create new tokens?

• What about when the tokens are refreshed asynchronously?

  Let's imagine a scenario where the user is inside the app, and at least two server calls are run asynchronously:

  • "Service1" makes a server call with an expired accessToken1 and a refreshToken1, and the server responds by sending a new accessToken2 and refreshToken2
  • Before receiving the "Service1" response, "Service2" makes an other server call with accessToken1 and refreshToken1, the server compares refreshToken1 to the previously saved refreshToken2 and finds them different. It responds then with an Invalid refresh token response, and this causes the user to be logged out!

  To avoid this problem and keep the user logged in, there could be a centralized authentication service that checks first the validity of the tokens before any server call is made. Which means that any call won't be executed unless the authentication service is idle, or wait for the new tokens if it's already loading.

  My second question here is:

  II. Having such a service to avoid the asynchronous refresh token problem means more round trips to the server, which might prove costly. Is there a better solution?

Answer 1

These are some very great questions you have asked, I have tried to answer them with my knowledge as I have also had the same questions when I studied about refresh tokens.

Regardless of how the attacker gets hold of the tokens from the user environment, would he be able to use them indefinitely as long as the user is still inactive and isn't logged in again with his credentials to create new tokens?

Answer:- Here, the solution is not binary, It's about how hard we can make it for the attacker to get the resource, this solution which you have told us prevents a lot of cases because the probability of users using their refresh token before the attacker accesses their resources is random and it gives us flexibility to invalidate that attacker's token if we found anything suspicious with our account, so it's always better from a case where attacker can use your access token to access your resources for lifetime.

Having such a service to avoid the asynchronous refresh token problem means more round trips to the server, which might prove costly. Is there a better solution?

Answer:- Correct me if I am wrong, but what I understood from your question is that exchanging a refresh token for new access and a refresh token is costly, so we can always adjust this exchange rate by defining a proper expiry for your access tokens depending on your use case, here we are trading cost and speed for security so, if we need a cheap solution we can always set the expiration of access token to a large interval and of cause it will be less secure.

Answer 2

There are some steps to login / revoke access to an api:

• When you do log in, send 2 tokens (Access token, Refresh token) in response to the client.
• The access token will have less expiry time and Refresh will have long expiry time.
• The client (Front end) will store refresh token in his local storage and access token in cookies.
• The client will use an access token for calling APIs. But when it expires, pick the refresh token from local storage and call auth server API to get the new token.
• Your auth server will have an API exposed which will accept refresh token and checks for its validity and return a new access token.
• Once the refresh token is expired, the User will be logged out.

JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed—for example, using public/private key pairs—you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn't been tampered with.

What about when the tokens are refreshed asynchronously?

that supposed be done with a single request to an endpoint, so there is a single accessToken

Having such a service to avoid the asynchronous refresh token problem means more round trips to the server, which might prove costly. Is there a better solution?

i think that's the best & secure solution for mobile and serverless apps, token are like ssh keys must be kept secure all the time :)

for more information check [question]: JWT refresh token flow

Here's the official introduction to JWT