Does I understand access and refresh token technique for authentication correctly?

Question

After doing some research in using JWT with Access Token and Refresh Token for authentication. I understand this in this way.

• After login, return to user Access Token and Refresh Token (using same technique JWT for both).
• Saving Refresh Token in Database (one User can have multiple Refresh Tokens for multiple devices).
• Whenever user sends a request with invalid Access Token, check Refresh Token and call another api to get new Access Token (doing this in client side). After that, call api to get data again with new Access Token.
• If Refresh Token is invalid, deleting its record in database and user must to login again to get new Refresh Token.

Does I understand Access and Refresh Token technique correctly? Please give me some advices. Thank in advance.

Answer 1

The way I see it, your refresh token needs to be stored and associated with the device and the user.

Example: User Logs In in Device A

1. Call Login endpoint
2. Validate user is valid
   1. If valid, generate a refresh token associated with the userid & device id
   2. store required data to your table or storage engine (user_sessions..etc) user_id | device_id | refresh_token | expires_at
   3. Return the payload with access_token, refresh_token , access_token_expires_at, refresh_token_expires_at
   4. Front-end, store the payload
3. when consuming a resource, check the following
   1. If refresh_token_expires_at > now then logs them out , show your session is timeout (or you can have a never expired refresh_token.. ex. refresh_token_expires_at can be 0)
   2. if access_token_expires_at > now then call refresh token endpoint along with your payload.
   3. on the refresh endpoint, validate the call and check the refresh token against the data stored.
      1. if refresh token is valid for this user+device, generate a new access_token
      2. return the access_token and its expires_at
      3. If the refresh token is INvalid , return invalid
      4. front end will log the user out.

** in any case, if a refresh token was compromised, it will be only for that particular device/user. A user can then deactivate or remove the device from their list. This action will invalidate the refresh_token on their next refresh call.

Answer 2

Of the 4 steps you listed, some look more or less correct while others do not. I will begin this answer by giving the premise for why refresh tokens were created and what is their main purpose.

Using the JWT pattern with only access tokens, there is a potential usability problem when the JWT token expires. Consider as an example a banking website. When a user logs in, he receives a JWT token with a certain expiry (typically stored under the exp key in the claims section of the token). If the token is given say a 5 minute expiry, then from a usability point of view, it means that the website would have to force the user to manually login every 5 minutes. Obviously, this is not the best user experience, because it means that a user who happens to be in the middle of some business process when the token expires might lose all that work. This is where refresh tokens step in to alleviate this problem.

Using the JWT pattern with refresh tokens means that the user receives both an access and a refresh token. A typical workflow here might be:

• After login, return to user Access Token and Refresh Token (using same technique JWT for both). The receiver notes when the access token is set to expire (say 15 minutes).
• As the expiry of the access token approaches (e.g. 10 minutes), the UI will send the refresh token to the backend to obtain a new access token (and refresh token). This could be done explicitly, e.g. on a website which displays a popup asking if the user wants to continue. Or it could be done in stealth mode, with a REST call being made under the hood to get the new access token.
• For the edge case where the refresh token cannot be used to obtain a new access token, then the very next user action which requires authentication would fail. In this case, the user would have to redirected to the login page. But, as this case should generally be rare, it does not disqualify the refresh token pattern.

I would also point out that storing the access/refresh tokens in the database largely defeats the purpose of the JWT pattern. One major reason for using JWT is that it pushes the user session state out of the application and onto the user. By storing tokens in your database, you are totally making your user sessions very stateful, which has all sorts of potential drawbacks. Consider using the suggested workflow above to avoid doing this.