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?
