I'm creating a backend that supports authentication with JWT tokens. I'm using the classic access token / refresh token combo.

  • the access token is valid for 5 minutes and allows the users to perform some actions. It's not checked against the database, it's valid until it expires
  • the refresh token is valid 1 week and can only be used to get a new access token

I'm enquiring about best practices here, when it comes to getting a new access token. As of now, I have a middleware on the backend side. The middleware checks the access token in the header of each request:

  • if the access token is still valid, allow the request
  • if the access token is expired, fetch the refresh token from the header too. The refresh token is then checked against the database
  • if a new access token was issued, it's returned to the client for subsequent queries

The advantages of the setup above IMO is that everything happens in one query. That also implies that my access token can have a short lifetime (5 min). I'm sending the refresh token in a header instead of a cookie because my client is developed with Flutter (so the client can be an Android app or web).

I've been looking for strong reasons to NOT do that. Here for example: Using OAuth2 with JWT, should a client pass along unused refresh tokens on a logout call?, the answer says:

[it] is not ideal as it increases the chance of leaking

I'm wondering exactly how risky it is that a leak will happen, especially with a https app.

The alternative way to do this would be to try and send a request to the backend with just the access token, and if a 401 happens (and it's an expired access token), get a new access token by sending the refresh token to the backend.

What would be the most standard way to do this?

  • 2
    In the original concept you have an identity provider issuing the access and refresh token and a resource only capable of checking an access token. So in this scenario it is not possible to automatically generate a new refresh token (at least if you only make one request).
    – Robert
    May 2 at 10:11
  • In this case the refresh token is the token and there's not really much reason why you would use a separate access token. Then what you are asking is: what is the advantage of having a separate access token that is not the same as the refresh token?
    – user253751
    May 2 at 21:27
  • No that's not what I'm asking. There are still clear benefits of having the access AND refresh tokens: checking the refresh token triggers a DB query (and potentially other expensive checks), but not the access one. The refresh token can only be used to get an access token, not to do stuff (better if an attacker gets it). Only the refresh token needs to be stored. The access token expires quickly. Etc. @Robert: you're saying "this is the way it has always been done". I'm looking for reasons it was done like this. And why doing it in one query would be "bad".
    – Rififi
    May 3 at 17:38


You must log in to answer this question.

Browse other questions tagged .