Can I reuse the refresh token as the remember me token?

Question

I have an application with a server-client architecture. The server is a REST/JSON API and the client reaches to the server via HTTPS. I currently have a short-lived access token (JWT, stateless, 15 minutes) that is attached for each authenticated request and a long-lived refresh token (random, stateful, 7 days). The refresh token can be used to exchange for a new access token if the old access token has expired.

My question is do I need an even longer-lived remember-me token (e.g. 30 days) that the client can use to get a new refresh token, or can I just extend the duration of the refresh token and use it as a remember-me token? Am I exposing myself to some kind of attacks by reusing the refresh token as the remember me token?

Answer 1

If your current refresh token is valid for multiple uses and expires only once it's lifetime exceeds, you might have issues tracking token replay and revoke the token (I assume that is what you mean with stateful?) Ideally refresh tokens should be one time use only (hence the "nonce" claim). What you can do is refresh token rotation, i.e. issuing a new refresh token once the access token gets exchanged and invalidating the old token (this step is crucial, as you can now detect if some malicious third party attempts to re-use the token and act accordingly by invalidating its successor or informing the user from whom the token was nicked).

Effectively a user gets infinite access as long as the refresh token lifetime never exceeds an inactivity period of the user (not considering small time skew of up to 15 minutes if he quits right before the token would be refreshed).

Naturally that brings other issues, especially when a malicious user gets his hand on the refresh token in a period of time the resource owner is absent for longer, making it virtually impossible to detect the misuse until the latter uses the token as well and replay is detected. This article explains the whole set-up and its issues quite well (I also snatched the image from there).

If you want to avoid potentially infinite misuse you could add some sort of master expiration date that is set within the initial refresh token upon actual password login and kept by every subsequent refresh token (if it is set to 30 days, your user will inevitably have to re-enter his password after that period).

In the end you will always loosen security for the sake of usability, bit I think a "refresh refresh token" is not the way to go here.