Application Security

Fortify Your API: Implementing JWT with Short-Lived Access Tokens and Refresh Token Rotation

May 5, 2026 · 51 views
web developmentOWASPauthenticationjwtsecurityRefresh Token

In the modern landscape of web application security, the debate between JSON Web Tokens (JWTs) and session-based authentication continues to evolve. While JWTs offer statelessness and scalability, they come with inherent risks, primarily centered around token theft and the difficulty of revocation. The industry-standard best practice to mitigate these risks is a dual-token strategy: using extremely short-lived access tokens paired with securely managed, rotating refresh tokens. This approach minimizes the window of opportunity for attackers while maintaining a seamless user experience.

The Vulnerability of Long-Lived Tokens

Traditional JWT implementations often set an expiration time (exp) of several hours or even days. While convenient, this creates a significant security vulnerability. If an access token is intercepted via Cross-Site Scripting (XSS), network sniffing, or a compromised client, the attacker has that entire window of time to impersonate the user. Unlike server-side sessions, which can be invalidated immediately on the server, JWTs are self-contained. Revoking a long-lived token requires a "blocklist" or a distributed cache (like Redis) to check validity, which adds latency and complexity.

By shrinking the access token lifetime to mere minutes (e.g., 15 minutes), the attack surface is drastically reduced. Even if a token is stolen, it becomes useless almost immediately. However, this introduces a new problem: how do users stay logged in without constantly re-entering credentials? This is where refresh tokens come into play.

Introducing Refresh Token Rotation

A refresh token is a long-lived credential used to obtain new access tokens. The critical security enhancement here is rotation. In a naive implementation, a refresh token is reused until it expires. This makes it vulnerable to token replay attacks; once stolen, an attacker can continuously use it to generate new access tokens.

With rotation, every time a refresh token is used to get a new access token, a brand new refresh token is generated and issued. The old refresh token is immediately invalidated. This creates a "moving target" for attackers. If an attacker steals refresh token A and uses it, the server issues access token B and refresh token C, while simultaneously blacklisting token A. The attacker is locked out, while the legitimate user seamlessly receives the new credentials in the background.

Implementation Strategy

Implementing this pattern requires careful handling of the token lifecycle. Below is a conceptual Node.js/Express example demonstrating the rotation logic. The key is that the refresh token stored in your database must be unique per user session and change on every successful authentication event.

// Pseudo-code for token rotation logic
const jwt = require('jsonwebtoken');
const crypto = require('crypto');

// 1. User logs in or refreshes token
async function handleTokenRequest(refreshToken) {
  // Find the refresh token in your database
  const storedTokenData = await db.findRefreshToken(refreshToken);

  if (!storedTokenData || jwt.verify(refreshToken, process.env.REFRESH_SECRET) === false) {
    throw new Error('Invalid refresh token');
  }

  // 2. Rotate the refresh token
  // Generate a new refresh token
  const newRefreshToken = jwt.sign(
    { sub: storedTokenData.userId, jti: crypto.randomUUID() }, 
    process.env.REFRESH_SECRET, 
    { expiresIn: '7d' }
  );

  // 3. Invalidate the old token in the database
  // Crucial step: The old token is now useless
  await db.invalidateToken(storedTokenData.jti);

  // 4. Save the new token with a unique JTI for next rotation
  await db.saveRefreshToken(storedTokenData.userId, newRefreshToken, crypto.randomUUID());

  // 5. Issue a short-lived access token
  const accessToken = jwt.sign(
    { userId: storedTokenData.userId }, 
    process.env.ACCESS_SECRET, 
    { expiresIn: '15m' }
  );

  return { accessToken, newRefreshToken };
}

Best Practices for Enhanced Security

  • Secure Storage: Access tokens should only be stored in memory. Refresh tokens should be stored in httpOnly, secure, SameSite=Strict cookies to prevent XSS theft. Never store tokens in localStorage.
  • Unique JTI: Always include a JWT ID (jti) claim in your refresh tokens. This allows you to uniquely identify and revoke specific tokens, which is essential for the rotation mechanism to work effectively.
  • Sliding Window: Consider implementing a sliding expiration window for refresh tokens. If a user is active, extend their refresh token lifetime, but cap the maximum absolute lifetime (e.g., 7 days or 30 days) to force periodic re-authentication.
  • Detect Abuse: Monitor for multiple concurrent sessions or suspicious IP changes. If a refresh token is used from a new device, consider requiring additional verification or logging out all other sessions.

Conclusion

Implementing short-lived JWTs with refresh token rotation is not just a security checklist item; it is a fundamental architectural decision that balances security and usability. By minimizing the lifespan of active access tokens and ensuring that refresh tokens cannot be reused after a single use, you significantly harden your application against token theft and replay attacks. While this approach adds complexity to your authentication flow, the reduction in risk is substantial. For any application handling sensitive data, this pattern is no longer optional—it is essential.

Share:
Related Posts