How to Debug JWT Expiration and Invalid Signature Errors

The 4 Most Frequent JWT Authentication Failures

TokenExpiredError / jwt expired

HTTP 401 Unauthorized

Root Cause: The current system time has passed the value defined in the 'exp' claim.

How to Fix: Implement automatic token refresh routines or grant a 15–30 second clockTolerance buffer on the backend validator.

JsonWebTokenError: invalid signature

HTTP 403 Forbidden / 401

Root Cause: The secret/public key used for verification does not match the key used to sign the token, or the payload was tampered with.

How to Fix: Verify that the backend environment variable (e.g. JWT_SECRET) matches the issuing service, and confirm the signing algorithm (HS256 vs RS256).

NotBeforeError / jwt not active

HTTP 401 Unauthorized

Root Cause: The token contains an 'nbf' timestamp that is set to a future date/time.

How to Fix: Check server clock synchronization between the token issuer and consumer using NTP.

JsonWebTokenError: jwt malformed

HTTP 400 Bad Request

Root Cause: The incoming authorization header is missing dots, contains invalid Base64URL characters, or includes extra whitespace.

How to Fix: Ensure your client request prepends 'Bearer ' properly and does not truncate token strings.

1. Fixing Server Clock Skew Discrepancies

In cloud architectures where microservices run in different availability zones or Docker containers, server system clocks can drift by a few seconds. If an authentication service issues a token at 12:00:00 with a 60-second expiration, but an API gateway's clock is running 5 seconds fast (at 12:00:05), the token may appear expired prematurely.

To resolve clock drift, production JWT verification libraries support a clock tolerance (or leeway) setting. Here is how to configure it in Node.js (jsonwebtoken):

// Node.js JWT Verification with 30-Second Clock Toleranceconst jwt = require("jsonwebtoken");

try {
  const decoded = jwt.verify(token, process.env.JWT_SECRET, {
    algorithms: ["HS256"],
    clockTolerance: 30, // 30-second leeway buffer
  });
} catch (err) {
  if (err.name === "TokenExpiredError") {
    // Trigger refresh token rotation
  }
}

2. Resolving "Invalid Signature" Errors

An invalid signature indicates that the mathematical hash computed by the verifying server does not match the third segment of the JWT. The most common reasons include:

Symmetric vs. Asymmetric Mismatch: If your authorization server signs tokens using RS256 (RSA private key), your API server must verify using the matching RSA public key (or JWKS URL), not an HMAC secret string.
Environment Variable Issues: Trailing newlines (\n) or missing quotation marks around secret keys in .env files cause different key strings across development and production containers.
Reverse Proxy Header Mutation: Proxies or CDNs modifying character encoding in the Authorization header can inadvertently alter Base64URL characters.

3. The Silent Refresh Architecture

Instead of forcing users to log in again every time an access token expires, modern web applications implement the Silent Refresh Pattern using an HTTP-only refresh token:

The user logs in and receives a short-lived Access Token (15 min) and an HttpOnly Refresh Token cookie (7 days).
The client uses the access token for API calls.
When an API endpoint responds with 401 TokenExpiredError, an Axios or Fetch interceptor catches the response and requests a fresh access token from /api/auth/refresh.
The server validates the refresh token, issues a new access token, and retries the original API call seamlessly without disturbing the user.

Complementary Diagnostic Utilities on Silixen

JWT Decoder & Debugger

Paste any token to view claims, inspect the header algorithm, and check expiration timing.

Website Uptime Checker

Verify whether your authentication endpoint is responding with healthy HTTP status codes.