Add refresh token rotation and detect and block replay attempts

[tjementum]

[PavlovicDzFilip]

I'm wondering whether it's truly possible to fully protect against replay attempts with our current setup.

According to the Auth0 documentation, we need to invalidate the entire Refresh Token Family whenever an outdated refresh token is used.

In scenarios where the frontend sends only one request at a time, this approach works fine. However, at PlatformPlatform, the frontend often fires off multiple concurrent requests.

These requests use the same refresh token. The first one to hit the backend and request a new access token succeeds and bumps the version of the Refresh Token Family. The subsequent requests, still using the now-outdated token, are flagged and cause the entire family to be invalidated, effectively logging the user out.

One potential solution could be to introduce a short grace period during which older versions of a refresh token are still accepted. However, this opens a security risk: if an attacker gains access to the HttpOnly cookie holding the refresh token, they might exploit this window.

An alternative is to ensure the frontend always has a valid access token before sending any requests. We could introduce a new endpoint to assist in this, requiring the frontend to manage state more proactively. Specifically, if no access token is available, the frontend should try to refresh the token first. But with PlatformPlatform using HttpOnly cookies, this approach isn't straightforward.

A possible workaround is to issue an additional dummy cookie that expires alongside the access token. The frontend could then check for this cookie’s presence before sending any requests. If it's missing, the frontend initiates a token refresh; failure to do so should result in logging the user out.

With this strategy, legitimate clients won't trigger concurrent refresh attempts, allowing us to rely on the Auth0-provided mechanism safely.

Would love to hear thoughts on this direction—or if there's a better approach we should consider.

[tjementum]

The reason this issue is not closed is exactly what you describe. With multiple frontend requests running in parallel, we need to have a grace period of, e.g., 20 seconds (default request timeout in PlatformPlatform) where we will accept old refresh tokens. AND these parallel requests should all return the same (new) refresh token.

If an attacker gains access to the HttpOnly refresh token, it's always bad. The most likely situation is that someone with access to a computer (say a colleague) grabs the refresh token from the browser storage and adds that cookie to their own browser. Unless you have an extremely chatty app that is making new requests all the time (and makes this grace period window predictable), this will only be possible if the attacker has a way to monitor when the client makes a request. In which case, you have an even bigger problem.

I don't like having logic in the frontend that deals with this, as this will make the frontend unreasonably complex (like a lot).