Issue with Refresh Token Rotation in Nested Routes using session cookie

[axbegue]

I am developing an application with a frontend in Remix and a backend in Nest. I use JWT for security and have implemented a Refresh Token rotation system for enhanced security.

In the frontend, authentication is performed with the backend, receiving and storing the Access and Refresh Tokens in an encrypted session cookie. When accessing protected resources, the frontend checks the validity of the Access Token and, if expired, uses the Refresh Token to obtain new tokens.

However, I am facing a challenge: in scenarios with nested routes and multiple loaders accessing the database simultaneously, if the Access Token expires, both loaders try to refresh the token at the same time. This causes the Refresh Token rotation system in the backend to detect a security breach and block the token, as the same family ID tries to access the server twice.

Has anyone faced a similar issue or has suggestions on how to handle this situation?

Any advice or shared experience would be greatly appreciated.

[sergiodxa]

I did this once and my recommendation is to move the refresh of the access token to the HTTP server (e.g. Express), that way you can do it once for all loaders in a document request. At least until #7642 is implemented.

Note that on a client-side navigation loaders will create separate requests so in that scenario you may refresh the token multiple times, here even middlewares will not be able to help, but #7640 will solve it by doing one request for all loaders in a client-side navigation.

Another recommendation is to generate long-lived access tokens, since the token is stored safely in an encrypted session cookie (and I imagine with httpOnly too) there's no reason to have short lived access tokens, so you can let the token be valid for a year if you want as far as you have a way to invalidate it.

[axbegue]

The issue I foresee with shifting the validation and refresh to Express is that with client-side route navigation, each request to loaders translates into one request to Express. So the same problem could happen, or I'm wrong?.

I am considering not mutating the session in loaders. If the access token is expired, the loader would simply return an error indicating 'Access Token Expired', and then post to an action for the refresh. The only drawback here is that it would necessitate two server round trips instead of one.

This update will solve the problem I think #7640, because there will always be just one request to the server, similar to the initial page load or an action post.

[sergiodxa]

The issue I foresee with shifting the validation and refresh to Express is that with client-side route navigation, each request to loaders translates into one request to Express. So the same problem could happen, or I'm wrong?

Yes, I mentioned this and linked to that RFC discussion.

What you could probably do is to update your backend so if the access token was refreshed recently it doesn't refresh it.