[Bug]: Silent Refresh Path Bypasses Refresh Token Revocation and Rotation Checks

[riya-chauhan12]

Before submitting

• I have searched existing issues to make sure this is not a duplicate.
• I have read the contribution guidelines.

Bug summary

The authentication middleware contains a silent-refresh flow that issues a new access token using only JWT signature validation of the refresh token. Unlike the /api/auth/refresh endpoint, this path does not verify the refresh token against the stored security.refreshTokenHash. As a result, refresh tokens that have been revoked through logout or invalidated through token rotation can continue to be used to obtain new access tokens until the refresh token JWT itself expires.

Steps to reproduce

Log in and obtain an access token and refresh token.
Call POST /api/auth/refresh to rotate tokens.
The original refresh token should now be invalid because a new hash is stored in the database.
Allow the access token to expire.
Send an authenticated request using:
expired access token
original refresh token cookie
Observe that the middleware silently generates a new access token and the request succeeds.

The same behavior occurs after logout if the old refresh token cookie is preserved.

Expected behavior

Refresh-token revocation and rotation should be enforced consistently across all authentication flows.

A refresh token that has been revoked through logout or superseded through rotation should not be able to obtain a new access token, regardless of whether the request uses the explicit refresh endpoint or the middleware's silent-refresh mechanism.

Actual behavior

The explicit refresh endpoint validates refresh-token state against persisted session data, while the middleware silent-refresh flow appears to rely solely on JWT verification.

As a result, revoked or rotated refresh tokens may continue to be accepted until their JWT expiration time is reached.

Screenshots or recordings

No response

Browser and device information

Browser:
Browser version:
Operating system:
Device:
Screen size/resolution:

Additional context

No response

[riya-chauhan12]

Hi @kunalverma2512,
I would like to work on resolving this issue under GSSoC. Kindly assign it to me.
Thank you.

[kunalverma2512]

@coderabbitai please do a in deep reasoning about the claim or claims in this issue description with respect to whole codebase and find out how this bug causes errors or what it spread and how it is affecting the backend and what user will face due to this issue
Explain the issue more nicely and with actual code and all codes who are responsible for this behaviour
whats the remedy and how it will make the future code health better and whats this issue solution will give us value in long term
NOTE:make sure you see the codebase and then tell honest,insane and detailed explaination

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch the issue details
gh issue view 208 --repo kunalverma2512/CodeLens --json title,body,labels,comments

Length of output: 3913

---

🏁 Script executed:

#!/bin/bash
# Explore the overall structure of the codebase
tree -L 3 --dirsfirst 2>/dev/null || find . -maxdepth 3 -type d | head -60

Length of output: 1869

---

🏁 Script executed:

#!/bin/bash
# Look for backend related files
fd -e js -e ts -e py -e go -e java --type f | head -80

Length of output: 2360

---

🏁 Script executed:

#!/bin/bash
cat server/middlewares/authMiddleware.js

Length of output: 3144

---

🏁 Script executed:

#!/bin/bash
cat server/utils/tokenHelper.js

Length of output: 2907

---

🏁 Script executed:

#!/bin/bash
cat server/modules/auth/service.js

Length of output: 16736

---

🏁 Script executed:

#!/bin/bash
cat server/modules/auth/controller.js

Length of output: 10689

---

🏁 Script executed:

#!/bin/bash
cat server/modules/auth/repository.js

Length of output: 2250

---

🏁 Script executed:

#!/bin/bash
cat server/models/User.js

Length of output: 2667

---

---

@kunalverma2512 Here is a deep, honest, and code-level breakdown of this security bug.

---

🔐 Deep Analysis: Silent Refresh Bypasses Revocation & Rotation

The Big Picture First

CodeLens has two paths that can mint a new access token using a refresh token:

Path	File	Does it check DB hash?
POST /api/auth/refresh	server/modules/auth/controller.js	✅ YES — full revocation check
authMiddleware silent refresh	server/middlewares/authMiddleware.js	❌ NO — JWT only

This asymmetry is the entire bug. One path enforces your revocation system. The other ignores it completely.

---

The Security Architecture (What Was Intended)

When a user logs in, #persistRefreshToken() in controller.js hashes the refresh token and stores it in the database:

// server/modules/auth/controller.js (lines ~183–188)
static async `#persistRefreshToken`(userId, refreshToken) {
  const hash = await bcrypt.hash(refreshToken, 4);
  await User.findByIdAndUpdate(userId, {
    $set: { "security.refreshTokenHash": hash }
  });
}

And on the User model, this field is intentionally hidden from normal queries:

// server/models/User.js (line ~59)
security: {
  refreshTokenHash: { type: String, select: false }  // ← must be explicitly selected
}

This is a well-designed revocation system. The intent: the raw JWT alone is never enough — it must also match the hash stored in the DB.

---

The Secure Path: POST /api/auth/refresh

The explicit refresh endpoint in controller.js follows this correctly (lines ~113–148):

static async refresh(req, res, next) {
  const refreshToken = req.cookies?.refreshToken;
  const decoded = verifyRefreshToken(refreshToken);           // ← Step 1: JWT check
  const userId = decoded.userId || decoded.id || decoded._id;

  // ← Step 2: Fetch the stored hash (select: false — must be explicit)
  const user = await User.findById(userId).select("+security.refreshTokenHash");

  const storedHash = user.security?.refreshTokenHash;
  if (!storedHash) {
    throw new ApiError(401, "Session has been revoked. Please log in again."); // ← Step 3: revocation check
  }

  const isValid = await bcrypt.compare(refreshToken, storedHash);  // ← Step 4: hash match
  if (!isValid) {
    await User.findByIdAndUpdate(userId, { $unset: { "security.refreshTokenHash": "" } });
    clearAuthCookies(res);
    throw new ApiError(401, "Invalid session. Please log in again.");
  }

  // Only THEN rotate tokens
  const newRefreshToken = generateRefreshToken(tokenPayload);
  await AuthController.#persistRefreshToken(user._id, newRefreshToken); // ← Step 5: rotate
  setAuthCookies(res, newAccessToken, newRefreshToken);
}

Four hardened steps: JWT → DB fetch → existence check → bcrypt compare.

---

The Vulnerable Path: authMiddleware Silent Refresh

Now look at authMiddleware.js (lines ~38–51) — the exact same operation, but with zero DB validation:

// server/middlewares/authMiddleware.js
if (err.name === "TokenExpiredError" && tokenSource === "cookie" && req.cookies?.refreshToken) {
  try {
    const refreshDecoded = verifyRefreshToken(req.cookies.refreshToken);
    //                      ↑ ONLY check: is the JWT signature valid?
    //                      ❌ No DB lookup
    //                      ❌ No check that security.refreshTokenHash exists
    //                      ❌ No bcrypt.compare against stored hash
    //                      ❌ No token rotation

    const userId = refreshDecoded.userId || refreshDecoded.id || refreshDecoded._id;
    const newAccessToken = generateAccessToken({
      userId,
      email: refreshDecoded.email,
      role: refreshDecoded.role
    });
    setAccessTokenCookie(res, newAccessToken);  // ← New access token issued!
    decoded = { userId, email: refreshDecoded.email, role: refreshDecoded.role };
  } catch {
    throw new ApiError(401, "Session expired. Please log in again.");
  }
}

A refresh token that is cryptographically valid but DB-revoked passes this check without issue, because the DB is never consulted.

---

Concrete Attack Scenarios

Scenario 1 — Post-Logout Account Persistence

1. Attacker or user logs in  →  refreshToken cookie is set (30-day JWT)
2. User logs out  →  logout() does:
      User.findByIdAndUpdate(userId, { $unset: { "security.refreshTokenHash": "" } })
      clearAuthCookies(res)
3. Attacker preserved the old refreshToken cookie value
4. Attacker makes any authenticated API call with:
      - expired accessToken  (even a forged one from curl)
      - the old refreshToken in the cookie
5. authMiddleware: access token expired → enters silent refresh branch
6. verifyRefreshToken(oldRefreshToken) → PASSES (JWT is still cryptographically valid for 30 days)
7. New access token is issued → request proceeds as fully authenticated

The logout effectively does nothing as long as the attacker has the refresh token cookie.

Scenario 2 — Token Rotation Bypass

1. User logs in on Device A  →  refreshTokenHash_A stored in DB
2. User calls POST /api/auth/refresh from Device B  →  refreshTokenHash_B replaces Hash_A in DB
   (The /api/auth/refresh endpoint correctly rotates — Hash_A is gone)
3. Device A's access token expires
4. Device A makes a request with its old (now-rotated-away) refreshToken_A
5. authMiddleware: verifyRefreshToken(refreshToken_A) → PASSES (JWT still valid)
6. DB hash says refreshToken_B should be the only valid token — but middleware never checks
7. Device A gets a fresh access token anyway

Token rotation's entire purpose — invalidating the old token when a new one is issued — is defeated.

Scenario 3 — Single Active Session Enforcement Broken

The DB model stores one refreshTokenHash per user. This means logging in on a new device was designed to implicitly invalidate all other sessions. But because every device using the middleware silent refresh path bypasses the DB check entirely, all previously logged-in devices continue functioning indefinitely.

---

Why It Hasn't Crashed the System (But Is Still Dangerous)

The bug is a silent security regression, not a runtime error. The server never throws — the middleware successfully issues tokens, the DB just isn't consulted. This means:

• No error logs
• No user-visible symptoms
• All API endpoints protect normally
• The only symptom is invisible: revoked sessions remain alive

This is the most dangerous class of security bugs — it causes no observable failures.

---

The Fix

The middleware's silent refresh branch needs the same four-step validation the /api/auth/refresh endpoint performs. Here's the corrected authMiddleware.js:

import { verifyToken, verifyRefreshToken, generateAccessToken, setAccessTokenCookie, clearAuthCookies } from "../utils/tokenHelper.js";
import User from "../models/User.js";
import ApiError from "../utils/ApiError.js";
import bcrypt from "bcryptjs"; // ← ADD THIS IMPORT

const authMiddleware = async (req, res, next) => {
  try {
    // ... token extraction code unchanged ...

    let decoded;
    try {
      decoded = verifyToken(token);
    } catch (err) {
      if (err.name === "TokenExpiredError" && tokenSource === "cookie" && req.cookies?.refreshToken) {
        try {
          // Step 1: JWT signature check (already present)
          const refreshDecoded = verifyRefreshToken(req.cookies.refreshToken);
          const userId = refreshDecoded.userId || refreshDecoded.id || refreshDecoded._id;

          // Step 2: Fetch user with the hidden refreshTokenHash field
          const userWithHash = await User.findById(userId).select("+security.refreshTokenHash");
          if (!userWithHash) {
            throw new ApiError(401, "Session expired. Please log in again.");
          }

          // Step 3: Check that a hash exists (if not — session was revoked via logout)
          const storedHash = userWithHash.security?.refreshTokenHash;
          if (!storedHash) {
            clearAuthCookies(res); // clean up client-side cookies
            throw new ApiError(401, "Session has been revoked. Please log in again.");
          }

          // Step 4: Verify the token matches the stored hash (rotation/theft check)
          const isValid = await bcrypt.compare(req.cookies.refreshToken, storedHash);
          if (!isValid) {
            // Possible token theft — invalidate the session entirely
            await User.findByIdAndUpdate(userId, { $unset: { "security.refreshTokenHash": "" } });
            clearAuthCookies(res);
            throw new ApiError(401, "Invalid session. Please log in again.");
          }

          // All checks passed — issue new access token
          const newAccessToken = generateAccessToken({
            userId,
            email: refreshDecoded.email,
            role: refreshDecoded.role
          });
          setAccessTokenCookie(res, newAccessToken);
          decoded = { userId, email: refreshDecoded.email, role: refreshDecoded.role };

        } catch (silentRefreshErr) {
          if (silentRefreshErr instanceof ApiError) throw silentRefreshErr;
          throw new ApiError(401, "Session expired. Please log in again.");
        }
      } else {
        throw new ApiError(401, "Invalid or expired token.");
      }
    }

    // ... rest of middleware unchanged ...
  }
};

Only two files need changing:

1. server/middlewares/authMiddleware.js — add the DB hash validation shown above
2. No changes needed to tokenHelper.js, User.js, controller.js, or service.js

---

Long-Term Code Health Value

Benefit	Details
Logout actually works	clearAuthCookies + DB hash removal together fully terminate a session
Token rotation is meaningful	Rotating via /api/auth/refresh will now actually invalidate the old refresh token across both code paths
Single active session	One hash in DB = one valid session; new login on device B will correctly kill device A
Theft detection works end-to-end	The isValid = false → $unset → 401 theft detection path in /api/auth/refresh now also applies to middleware
Consistency	Both refresh code paths share the same security contract — easier to reason about, audit, and test
Defense in depth	JWT verification alone is never sufficient for long-lived tokens; DB state is the ground truth

The core principle the fix enforces: a JWT being cryptographically valid is a necessary but not sufficient condition for a refresh token to be trusted. The DB hash is the authoritative revocation record.

🐇 (\_/) 🔍
( •.•) — digging into the auth layers

[kunalverma2512]

@riya-chauhan12

Thank you for your interest in working on this issue.

This is a valuable security-focused issue that touches some important authentication concepts such as session revocation, token rotation, and refresh-token validation. Taking the time to understand the complete flow before implementing the fix will not only help you resolve the issue correctly but will also strengthen your understanding of real-world backend security practices. I'm confident you'll learn a lot from working through it.

I've assigned this issue to you. Please investigate the affected authentication paths carefully, validate your solution against the different scenarios described in the issue, and come forward with a clean, well-structured, and legible PR. Wishing you the very best . I look forward to reviewing your implementation.

PLEASE JOIN CODELENS COMMUNITY,DEVELOPEMENT AND WELCOME ROOM FOR SUPPORT AND MAKE SURE TO UPDATE IN THAT GROUP ALSO
IF YOU FIND ANY DOUBT THEN FEEL FREE TO PUT IN THAT COMMUNITY CHANNEL

Good Luck

[kunalverma2512]

@riya-chauhan12 what about the update ?

[riya-chauhan12]

Hi @kunalverma2512,

I've submitted a PR addressing this issue: #211.

The fix adds refresh token hash validation to the silent refresh flow to ensure revoked refresh tokens cannot be used to obtain a new access token.

I also reproduced the issue locally and verified the behavior before and after the fix to confirm the issue is resolved.

When you have a chance, I'd appreciate a review. Please let me know if there are any changes, improvements, or additional tests you'd like me to make.

Thank you!