JWT Expired Token Troubleshooting – Fix Clock Skew Outages

Tokens appear expired the moment they are issued because servers disagree on time. When the validating server's clock is 90 seconds ahead of the issuing server, every token that expires in under two minutes fails immediately — even when the user just logged in. Decoding the exp and nbf claims shows the exact timestamps involved, so you can measure the skew and set the correct clock tolerance in your validation logic.

Clock skew is the most common cause of JWT expiry failures that cannot be reproduced locally. The development environment runs on a single machine with a synchronized clock; staging and production span multiple servers across regions. A JWT decoder surfaces the raw Unix timestamps in the payload so you can compare them against the current server time on both the issuing and validating side.

// Decoded JWT payload — clock skew scenario
{
  "sub": "usr_abc123",
  "iss": "https://auth.example.com",
  "aud": "api://v2",
  "iat": 1711576800,   // ← issued at: 2024-03-27T18:00:00Z
  "nbf": 1711576800,   // ← not before: same as iat
  "exp": 1711576860,   // ← expires at: 2024-03-27T18:01:00Z — only 60 seconds later
  "scope": "read:profile"
}

// If the validating server's clock reads 18:01:30Z, this token is already expired.
// Adding a 120-second clock skew tolerance to validation prevents the rejection.

What It Is

A JWT decoder splits a token into its three Base64 URL-safe segments — header, payload, and signature — and presents the payload claims as readable JSON. The exp claim is a Unix timestamp marking when the token expires; the nbf claim (not before) marks when it becomes valid. Both are expressed as seconds since the Unix epoch (January 1, 1970 UTC).

Decoding these claims does not require the signing key. The header and payload are only Base64-encoded, not encrypted — anyone with the token can decode and read the timestamps. Verification (confirming the token was issued by the expected authority) is a separate step that requires the public key.

Why Developers Use This

• Diagnosing clock skew outages. When authentication failures spike after a deployment, decoding the exp and iat claims and comparing them to the current server time shows whether the issue is skew, a misconfigured TTL, or something else entirely.
• Setting the correct skew tolerance. Most JWT libraries accept a clockTolerance or leeway parameter. Measuring the actual drift between issuing and validating servers tells you what value to set rather than guessing.
• Debugging short-lived tokens. Some auth configurations issue tokens with very short TTLs (60–300 seconds) for security reasons. Decoding the payload confirms whether the TTL is intentionally short or whether the auth service is misconfigured. See our guide on understanding JWT tokens for the full set of standard claims.
• Auditing token lifetimes. Security reviews often require confirming that tokens are not issued with excessively long TTLs. Decoding tokens from production samples confirms the expiry configuration is correct.

Common JWT Expiry Issues

• Clock skew. The validating server's clock is ahead of the issuing server's clock. Even a 60-second difference causes valid short-lived tokens to be rejected. Add a clock skew tolerance to the validation configuration.
• Audience mismatch. aud lists api://internal while your service expects api://public. A mismatched audience causes a rejection that looks similar to an expiry failure in generic error messages.
• Key ID drift. The kid header value points to a signing key that has been rotated out of the JWKS. After a key rotation, tokens signed by the old key fail verification until the old key is removed gracefully.

How to Use the JWT Decoder

Using the DevToolBox JWT Decoder to diagnose an expiry failure takes under two minutes.

1. Open the decoder in your browser. No account, no install.
2. Paste the full JWT — the three dot-separated segments.
3. The decoder immediately shows the decoded header and payload as formatted JSON.
4. Locate the exp value in the payload and convert the Unix timestamp to a human-readable datetime.
5. Compare that time to the current time on both the issuing and validating servers to measure the clock skew.
6. Set the clockTolerance parameter in your JWT library to a value that covers the measured drift.

DevToolBox tools run entirely in your browser — nothing you paste is transmitted to any server.

Frequently Asked Questions

Conclusion

Clock skew outages are invisible until you decode the token. The exp and nbf timestamps in the payload are the evidence — comparing them to the current server time on both sides of the validation pinpoints the drift. Once you know the skew, setting the correct tolerance in your JWT library resolves the issue permanently.

If you need a fast JWT decoder that shows all claims in readable JSON format, DevToolBox does exactly that. DevToolBox tools run entirely in your browser — no signup, no install, nothing sent to a server.