Is there a downside to sending a refresh token on every request to an API?

Question

Let's say that my user signs in and the server responds with a refresh token saved in a cookie (SameSite strict, HttpOnly, CSRF token too) and with the access token in response (saved in JS memory).

I read these guidelines in a popular Hasura article. I was wondering, though, with this method, my refresh token would be sent on every request since you can't remove a cookie from the client-side.

Is there a downside to this? I feel like sending a token that gives infinite/long-lived access on every request is a bad practice? If so, is there a better approach so that I don't send a refresh token on every request and only on the requests that I want to refresh my access token?

Other ways of doing this would be appreciated as well.

Answer 1

Have you considered using a nonce and a shared secret between the client and server? While not directly answering your question it is somewhat addressing the same challenge. The nonce would make hijacking the cookie futile.

In such a scenario the client and server share a secret. When a request is sent from e.g. the client to the server, a random nonce is generated, and you send {nonce, Hash(nonce, shared-secret)} to the server together with your message.

The server can then verify the authenticity of the client by hashing its shared-secret with the provided nonce.

You need to make sure the same nonce cannot be used twice.

Answer 2

As you imply sending the refresh token on every request is not ideal as it increases the chance of leaking. The simplest way to prevent this is to set the path attribute of your cookie to the token refresh endpoint. This way your refresh token is only attached to the request when you actually have a need of it.

Keep in mind though that since your refresh token is not attached to other requests it might interfere with middleware on the server that tries to auto-refresh on behalf of the client.