Is this an acceptable approach to refreshing JWTs?

Viewed 27

I'm in the process of rebuilding an existing web app, that uses JWTs to manage authentication. I'm still new to JWTs, so I'm learning about how they should work, while, at the same time, trying to understand why the web app's current implementation is the way it is.

The current version's flow is as follows:

  1. When a user successfully logs in or registers, a user object is returned along with a JWT property. This JWT is included in subsequent API calls as an Authorization header.
  2. Every ten minutes, a get request is made to API endpoint /refresh-token.
  3. If successful, the response body contains a success message, and the response header contains an updated Authorization header.
  4. All subsequent ten-minute timed get requests to /refresh-token use the original JWT that was returned in step 1, and so on.

From what I've read so far, this doesn't correlate with any recommended approaches.

Is it safe enough to replicate this flow in the newer version, or is this something I'm better off not replicating?

Edit: I'm working solely on the front-end - the API isn't being updated for a while, so I'm limited to what it currently returns.

1 Answers

I believe this article summarizes the current state of the art: https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/. You usually have two tokens. Access token which is short lived and an refresh token, which lives longer. This way you don't need to call the auth server every x minutes, but you can do it on demand.

I don't know if you need to deal with blacklisting too? I believe blacklisting is easier when you have a separation of access token and refresh token (only refresh token needs to be blacklisted). But I believe you could deal with this problem too, probably in a bit more sophisticated manner.

Having said that. What you have is not wrong. It's hard for me to point out any flaws in the way you are doing besides of what has been pointed out above.

Related