title: How to handle JWT refresh token in a mobile app environment
body: <p>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.</p>
  <p>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.</p>
  <p>Any correction or suggestion would be most welcome:</p>
  <ul>
  <li><p><strong>Why refresh tokens anyway?</strong></p>
  <p>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.</p>
  <p>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.</p>
  <p>My first question would be:</p>
  <p><strong>I.</strong> <em>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?</em></p>
  </li>
  <li><p><strong>What about when the tokens are refreshed asynchronously?</strong></p>
  <p>Let's imagine a scenario where the user is inside the app, and at least two server calls are run asynchronously:</p>
  <ul>
  <li>&quot;Service1&quot; makes a server call with an expired <code>accessToken1</code> and a <code>refreshToken1</code>, and the server responds by sending a new <code>accessToken2</code> and <code>refreshToken2</code></li>
  <li>Before receiving the &quot;Service1&quot; response, &quot;Service2&quot; makes an other server call with <code>accessToken1</code> and <code>refreshToken1</code>, the server compares <code>refreshToken1</code> to the previously saved <code>refreshToken2</code> and finds them different. It responds then with an <code>Invalid refresh token</code> response, and this causes the user to be logged out!</li>
  </ul>
  <p>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.</p>
  <p>My second question here is:</p>
  <p><strong>II.</strong> <em>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?</em></p>
  </li>
  </ul>