Managing Token Revocation with Refresh Token Rotation

In the early days of web development, stateful authentication was the standard approach for managing user identity. The server would create a session record in a database and return a unique identifier to the client, which was then stored in a browser cookie. While this worked well for single-server setups, it became a bottleneck as applications grew and required horizontal scaling across multiple data centers.

To solve the scaling issue, architects began adopting JSON Web Tokens as a stateless alternative. Because these tokens contain all the necessary user data and a cryptographic signature, the server does not need to query a central database to verify a user identity. This decoupling allows every microservice in a distributed system to validate requests independently and at high speed.

However, this stateless nature introduces a significant security challenge known as the revocation problem. Once a token is signed and issued, the server loses the ability to unilaterally cancel it before the expiration time is reached. This creates a dangerous window where a compromised token remains valid even if the user has changed their password or reported a theft.

To build a truly secure and scalable architecture, developers must balance the benefits of statelessness with a robust strategy for token management. This article explores how to implement a multi-layered security model using short-lived access tokens, refresh token rotation, and reactive blacklisting to maintain control over your authentication layer.

The first line of defense in a modern authentication system is the use of short-lived access tokens. By setting the expiration time to a narrow window, such as ten or fifteen minutes, you significantly limit the amount of time an attacker can use a stolen credential. If a token is intercepted, its utility is automatically neutralized as soon as the expiration timestamp in the payload passes.

While short-lived tokens improve security, they would create a poor user experience if the application forced users to log in every few minutes. To prevent this, we pair the access token with a long-lived refresh token that is stored securely on the client. This allows the application to transparently request a new access token in the background without interrupting the user workflow.

1const jwt = require('jsonwebtoken');
2
3const generateAccessToken = (user) => {
4  const payload = {
5    sub: user.id,
6    role: user.role,
7    // jti is a unique identifier for blacklisting purposes
8    jti: generateRandomString(16)
9  };
10
11  // Expires in 15 minutes to limit exposure window
12  return jwt.sign(payload, process.env.ACCESS_TOKEN_SECRET, {
13    expiresIn: '15m',
14    algorithm: 'HS256'
15  });
16};

The access token should contain the minimum amount of data required for the server to perform its tasks. Overloading the payload with sensitive information or large data structures increases the size of every HTTP request and can lead to header size limit errors. Use standard claims like sub for the user identifier and roles for authorization logic while keeping the payload as slim as possible.

A static refresh token represents a significant security risk because it can be used repeatedly to generate new access tokens over a long period. To mitigate this risk, we implement refresh token rotation, where the server issues a new refresh token every time the client uses the current one. This ensures that each refresh token is effectively a single-use credential.

This pattern allows the authentication server to detect replay attacks by tracking the history of issued tokens. If a server receives a refresh token that has already been used to obtain a new one, it suggests that the token has been stolen and used by two different parties. In this scenario, the server should immediately revoke all tokens associated with that user to protect the account.

• Issue a new access token and a new refresh token during every refresh cycle.
• Store the refresh token in an HttpOnly, Secure, and SameSite cookie to prevent JavaScript access and CSRF attacks.
• Validate the incoming refresh token against a database to ensure it has not been reused or revoked.
• Invalidate the entire family of tokens if an old refresh token is presented a second time.
• Limit the total lifespan of a refresh token family to force a full re-authentication after a set number of days.

Implementing this logic requires a database to store the active refresh token identifiers, which reintroduces a small amount of state to the system. However, this check only happens during the refresh cycle—which occurs once every fifteen minutes—rather than on every single API request. This keeps the primary application path fast and stateless while ensuring the security path is rigorous and stateful.

Despite using short-lived tokens, there are moments when a system must invalidate a token immediately, such as during a logout or when a user account is banned. Since we cannot modify a JWT that is already in the hands of the client, we use a server-side blacklist to track tokens that are no longer trusted. This blacklist typically stores the unique identifier of the token rather than the token itself.

Using an in-memory store like Redis for the blacklist ensures that verification checks are extremely fast and do not significantly impact request latency. When a user logs out, the application takes the token ID from the request and stores it in Redis with a Time To Live equal to the remaining lifespan of the token. This ensures the blacklist remains clean and only grows as large as the number of active revocations.

1const redis = require('./redis-client');
2
3const verifyAndCheckBlacklist = async (token) => {
4  const decoded = jwt.verify(token, process.env.ACCESS_TOKEN_SECRET);
5  
6  // Check if the unique token ID exists in the blacklist
7  const isBlacklisted = await redis.get(`blacklist:${decoded.jti}`);
8  
9  if (isBlacklisted) {
10    throw new Error('This token has been revoked');
11  }
12  
13  return decoded;
14};

Scalability is often a trade-off with immediate consistency; in authentication, this manifests as the gap between issuing a token and being able to take it back.

This hybrid approach gives you the best of both worlds by allowing most requests to be verified locally while providing a centralized mechanism for urgent security events. The blacklist check is only required for sensitive endpoints or during the initial request of a session, depending on the specific security requirements of your application. It provides the final piece of the puzzle for a robust authentication strategy.

Even with the best token strategy, your implementation is only as secure as the transport layer and storage mechanisms you use. Always serve your application over HTTPS to prevent man-in-the-middle attacks from capturing tokens in transit. Furthermore, configure your server to use the Strict-Transport-Security header to ensure that browsers never attempt to communicate with your API over an unencrypted connection.

When storing tokens in the browser, avoid using LocalStorage because it is accessible to any script running on the page, including malicious scripts from cross-site scripting attacks. Using cookies with the HttpOnly flag ensures that the token is only accessible by the browser for network requests and cannot be read or modified by client-side JavaScript. This simple configuration change eliminates an entire class of common security vulnerabilities.

Finally, ensure that your application has a strategy for secret rotation. The keys used to sign your tokens should be changed periodically to limit the impact of a potential key compromise. Use a key identification system in your JWT headers so that your server can support multiple active keys simultaneously during a rotation period, preventing any downtime for active users.