**TL;DR:** Users get kicked to sign-in or stuck in a loop, often only on some machines or containers. The token is fine; the verifying machine's clock is ahead of real time. Confirm the cause 1. Decode a failing token and compare its iat to current UTC time ON THE MACHINE THAT VERIFIES IT.

## The error

```text
. Often intermittent, often limited to specific servers, containers, or developer machines.

# Confirm the cause
1. Decode a failing token and compare its
```

## The fix

1. Decode a failing token and compare its `iat` to current UTC time ON THE MACHINE THAT VERIFIES IT. If iat is ahead of that machine's clock, you found it.

2. Check both sides: the backend verifying the token and the machine running the browser. Either being off breaks verification.

3. Containers and VMs drift without NTP. A clock even a minute ahead is enough to reject fresh tokens.

4. Sync the machine clock with a time server (enable NTP on the host; for containers, fix the host clock since most containers share it).

5. No code change is needed. This is infrastructure, not auth logic.

## When to use this

- You are seeing this exact error message; match the block above, not just part of it.
- The failing call matches the scenario in the title: 'JWT issued at date claim (iat) is in the future'.
- You want the fastest verified fix before digging through logs.

## When not to use this

- Your error text differs from the block above; close cousins often have different causes.
- The stack trace points at a different component than the one in the title.
- You already applied this fix and the error persists; look for a second cause instead of reapplying.

## Compatibility

- Not pinned to a specific version; follows current 'JWT behavior.