Should I Rotate My Refresh Token When Issuing a New JWT Access Token?

Below is an outline of best practices and some recommendations for handling refresh tokens when issuing new access tokens:

Refresh Token Rotation

It’s generally considered best practice to rotate (replace) the refresh token whenever a new access token is issued. This means that on the /auth/refresh endpoint:

• You issue a new access token.
• You also generate a new refresh token.
• You invalidate (or “revoke”) the old refresh token so it can’t be used again.

Benefits of Refresh Token Rotation

• Minimizing the Window of Exposure:
  If a refresh token is compromised, refreshing it on every use limits the time an attacker can use the stolen token.

• Replay Detection:
  By keeping track of token rotations (for example, storing a token identifier in your database), you can detect if an old token is attempted for reuse. Reuse may indicate a breach, so you can trigger additional security measures such as disabling the session.

• Improved Session Management:
  It allows you to manage sessions more securely since each refresh event resets the “timer” of the refresh token’s validity on a rolling basis.

Handling Invalidation of Old Refresh Tokens

To safely invalidate an old refresh token, consider these approaches:

1. Stateful Storage:
   Store refresh tokens (or their identifiers/hashes) in a database. When a new refresh token is issued:

   • Mark the previous token as “used” or delete it from your storage.
   • When a refresh token is presented, check its status in the database.

2. One-Time Use Tokens:
   Implement tokens that can be used only once. Once a refresh token is used successfully to get a new access token, immediately mark it as invalid or remove it from your storage.

3. Token Family Tracking:
   Link tokens as a “family” by recording a reference (e.g., a parent token ID). If an old token from a given family is seen after rotation, it indicates a possible token compromise.

Example Implementation (Node.js/Pseudocode)

Below is a simplified example in JavaScript showing the concept:

JAVASCRIPTCopied
// Example pseudo-code for refreshing tokens

async function refreshTokens(oldRefreshToken) {
  // Step 1: Verify the old refresh token
  const tokenRecord = await db.findRefreshToken(oldRefreshToken);
  if (!tokenRecord || tokenRecord.used) {
    throw new Error("Invalid or already used refresh token");
  }

  // Step 2: Invalidate the current (old) refresh token
  await db.invalidateRefreshToken(oldRefreshToken);

  // Step 3: Generate new tokens
  const newAccessToken = generateAccessToken({ userId: tokenRecord.userId });
  const newRefreshToken = generateRefreshToken({ userId: tokenRecord.userId });

  // Step 4: Store the new refresh token in the database
  await db.storeRefreshToken(newRefreshToken, {
    userId: tokenRecord.userId,
    expiresAt: calculateExpiry(7) // e.g., 7 days expiry
  });

  return { newAccessToken, newRefreshToken };
}

function generateAccessToken(payload) {
  // Implementation for creating short-lived access tokens (e.g., 15 minutes)
}

function generateRefreshToken(payload) {
  // Implementation for creating long-lived refresh tokens (e.g., 7 days) with a unique id
}

Summary Recommendations

• Yes, refresh the refresh token along with the access token.
  This minimizes risks associated with token theft and allows for detection of reuse.

• Ensure refresh tokens are one-time use tokens.
  Use persistence mechanisms to invalidate them once they are used. This could mean removing them from the database or flagging them as used.

• Balance Security and Complexity:
  While maintaining state (e.g., storing token IDs) adds complexity, it significantly improves your ability to detect and mitigate potential attacks.

Implementing such measures is inline with current best practices for securing token-based authentication systems.