1

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.

Quang Khải Đàm
  • 555
  • 1
  • 6
  • 21

2 Answers2

0

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.

Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360
  • I get it. But in this case, what is difference between Access Token and Refresh Token? Refresh Token in your case is just long lived version of Access Token. And if user want to expire all active Refresh Tokens (aka log out all session), this can not be done with Refresh Token just store on client side. – Quang Khải Đàm Oct 17 '20 at 17:16
  • @QuangKhảiĐàm A typical setup might be that a refresh token can only be used to obtain a new access token. It can't be used to do any other user actions (for which the access token itself is necessary). Doing a forced universal log out is another story. One way to do this would be to just have server side logic which rejects any JWT issued on before a certain date/time. – Tim Biegeleisen Oct 18 '20 at 02:35
  • So if Refresh Token is compromised, the whole system is compromised. Because there is no way to revoke Refresh Token (With Refresh Token, I can get any Access Token I want to call api). Could you explain this circumstance for me? Thanks – Quang Khải Đàm Oct 18 '20 at 04:28
  • I already did in the above comment. A missing token does mean that your whole system is "compromised;" that's the wrong word here. The worst case would just be that your service has to prompt the user to login/authenticate again, that is all. – Tim Biegeleisen Oct 18 '20 at 04:32
  • I mean the Refresh Token. It can be compromised if it just store on client side – Quang Khải Đàm Oct 18 '20 at 04:37
  • No, it can't be. If someone on the client side tries to hack the tokens then the checksum on the server, when it receives either token, would fail. It is _almost_ impossible for someone to hack a JWT locally and also know how to compute the proper checksum, without also knowing the server private key which it uses to sign the tokens. – Tim Biegeleisen Oct 18 '20 at 04:40
  • Why does it fail to checksum if I have refresh token from client? With this token, I can call api renew token to get a new access token and use that access token for calling private api legitimately even though I dont know what secret key is. – Quang Khải Đàm Oct 18 '20 at 04:56
0

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.

Justin Nguyen
  • 1