JWT Expired Still Accepted: Clock Skew Fix Guide

Nothing erodes trust in authentication like learning that expired tokens still open doors. Logout feels broken, offboarding stops working, and leaked tokens stay useful far past their stamped lifetime. Teams usually discover this during an audit or after a stolen token gets replayed days later, when the damage is already done.

Two causes explain nearly every case. Hand-rolled verification decodes the payload and checks the signature but never looks at exp at all. Or the library is configured with a generous leeway meant to cover clock skew, stretched to tens of minutes by someone chasing away occasional failures. Both leave the door open long after it should have closed.

The fix combines strict validation with short lifetimes. Validate exp and the surrounding claims on every request, cap skew tolerance near a minute, and issue access tokens that live for minutes while refresh tokens handle continuity. Clock discipline with NTP keeps servers agreeing on time.

This guide shows how to confirm the hole, tighten validation without breaking honest clients, and build the access-plus-refresh pattern that makes expiry meaningful again.

Why Expired Tokens Get Accepted: the Two Usual Gaps

Accept-after-expiry almost always traces to one of two gaps. The first is hand-rolled verification that decodes the payload, checks the signature, reads the role, and never glances at exp. It feels complete because every line looks security-related, yet the lifetime check is simply absent. Any signed token then works forever, including tokens from deactivated users.

The second gap is library verification with expiry disabled or leeway stretched beyond reason. Someone fighting sporadic failures sets leeway to 600 seconds or flips verify_exp off to calm the dashboard, and the change survives because nothing tests stale tokens. The stamped 30-minute lifetime becomes 40 minutes or infinity while the config comment still says clock skew.

Both gaps share a root habit: trusting issuance instead of verifying consumption. Setting exp at login is only half the job; each consumer must enforce it on every request. Audit the consume path, not the login path, when this bug is suspected.

Confirm with behavior, not reading. Mint a short-lived token, let it expire, and replay it. A 200 means the gap is real regardless of what anyone remembers about the config. That single test converts a vague suspicion into a concrete failing case the team can fix.

import time
import jwt

SECRET = 'test-only-secret'

def mint(lifetime_s: int) -> str:
    now = int(time.time())
    return jwt.encode({'sub': 'ana', 'iat': now, 'exp': now + lifetime_s}, SECRET, algorithm='HS256')

def strict_verify(token: str) -> bool:
    try:
        jwt.decode(token, SECRET, algorithms=['HS256'], leeway=90, options={'require': ['exp', 'sub']})
        return True
    except jwt.InvalidTokenError:
        return False

tok = mint(1)
time.sleep(2)
# Must be False: token is stale even inside small leeway.
print('stale accepted?', strict_verify(tok))
print('fresh accepted?', strict_verify(mint(600)))

Clock Skew Is Real but Small: NTP and Sane Leeway

Servers genuinely disagree about time. Virtual machines pause during migration, containers inherit host clocks, and NTP takes minutes to converge after boot. A token minted at second 100 on the issuer may arrive at a verifier that believes it is second 97. Without tolerance, honest tokens fail at the edges and engineers get paged for phantom outages.

The answer is small, explicit leeway plus healthy clocks. Cap tolerance at 60 to 120 seconds, which absorbs real drift while adding negligible replay risk. Then fix the clocks themselves: run chrony or systemd-timesyncd on every host, monitor offset with chronyc tracking, and block deploys on hosts with unsynchronized clocks. Containers should inherit from synced hosts, not carry their own drift.

Resist the urge to widen leeway when failures appear. A 10-minute tolerance that silences alerts also grants every stolen token 10 bonus minutes on every request. Investigate the skew first with date comparisons and NTP status across issuer and verifier; the fix is usually one unsynced host, not a config change.

Document the chosen value once and enforce it centrally. A shared verify helper with leeway pinned at 90 seconds beats five services with five opinions. Alert when any consumer overrides it, since widening tolerance is a security decision disguised as reliability tuning.

#!/usr/bin/env bash
set -euo pipefail
ISSUER_HOST="${1:?usage: clock_skew_check.sh <issuer-host>}"
echo "== local clock =="
date -u '+local UTC: %Y-%m-%dT%H:%M:%SZ'
if command -v chronyc >/dev/null 2>&1; then
  chronyc tracking | grep -E 'System time|NTP server' || true
elif command -v ntpq >/dev/null 2>&1; then
  ntpq -p | head -6
else
  echo 'no chronyc/ntpq found; confirm NTP via your platform agent'
fi
echo '== issuer clock (HTTP Date header) =='
curl -sI "https://$ISSUER_HOST/.well-known/jwks.json" | grep -i '^date:' || echo 'no Date header returned'
echo 'Drift over 120s means fix NTP, not widen leeway.'

Strict Claim Validation: exp, iat, iss, and aud Together

Expiry alone isn't enough; the surrounding claims stop token misuse across services and time. Validate exp so dead tokens die, iat to catch tokens minted in the future beyond skew, iss to confirm the expected login service issued it, and aud to confirm it was meant for your API. A token minted for the mobile API shouldn't open the admin panel just because the signature verifies.

Libraries do this well when asked. PyJWT's decode with require options and audience checks, java-jwt's acceptExpiresAt plus acceptIssuer, and jose equivalents all enforce the set in a few lines. The failure mode is always the same: defaults left permissive, audience unset because two services share tokens, or issuer unchecked after a migration added a second login path.

Standardize one strict helper per language in your repo and route every consumer through it. The helper pins algorithms, requires the claim set, caps leeway, and rejects unknown kids. New services import it instead of writing their own, which ends hand-rolled drift permanently.

Test the helper negatively: expired tokens, future-dated tokens, wrong issuer, and wrong audience must all receive 401s. Those four tests run in milliseconds and catch the exact misconfigurations that cause silent acceptance in production.

import jwt

SECRET = 'test-only-secret'
ISSUER = 'https://auth.example.com'

def verify_api_token(token: str) -> dict:
    return jwt.decode(
        token,
        SECRET,
        algorithms=['HS256'],
        issuer=ISSUER,
        audience='billing-api',
        leeway=90,
        options={'require': ['exp', 'iat', 'iss', 'aud', 'sub']},
    )

if __name__ == '__main__':
    import sys
    try:
        print(verify_api_token(sys.argv[1])['sub'])
    except jwt.InvalidTokenError as exc:
        print(f'401 unauthorized: {exc}')

Short Access Plus Refresh: Making Expiry Mean Something

Long-lived access tokens make every leak a long incident. A 24-hour token stolen at 9 AM works until tomorrow morning, surviving logout, password change, and even deactivation when expiry isn't checked. Shortening access to 5 to 15 minutes flips the math: the same leak buys minutes, while legitimate users never notice because refresh happens silently.

The refresh side carries the continuity. Refresh tokens live longer, travel only to the token endpoint, are stored securely (httpOnly cookies for browsers, secure storage for apps), rotate on each use, and revoke as a family on logout or suspicion. The server tracks refresh state, so revocation actually works, while stateless access tokens stay fast and small.

Rollout needs care around concurrency and reuse. Mobile apps with parallel requests can race refresh; accept the previous refresh briefly or serialize renewal. Treat refresh reuse as a theft signal: invalidate the whole family when a used token reappears, since only a cloned token could do that.

Measure the result directly. Plot access-token age at use time; after migration nearly every accepted token should be minutes old. The nightly stale-replay test then guards the property forever: any consumer answering 200 to yesterday's token pages immediately.

import secrets
import time

ACCESS_LIFE = 600  # 10 minutes
REFRESH_LIFE = 7 * 86400
_refresh_store = {}

def issue(user: str) -> dict:
    now = int(time.time())
    refresh = secrets.token_urlsafe(32)
    _refresh_store[refresh] = {'user': user, 'expires': now + REFRESH_LIFE, 'family': secrets.token_hex(8)}
    return {'access_exp': now + ACCESS_LIFE, 'refresh': refresh}

def refresh(old: str) -> dict | None:
    now = int(time.time())
    meta = _refresh_store.pop(old, None)  # rotation: single use
    if not meta or meta['expires'] < now:
        return None
    return issue(meta['user'])

pair = issue('ana')
print('access valid for (s):', ACCESS_LIFE)
print('rotated ok?', refresh(pair['refresh']) is not None)
print('reuse blocked?', refresh(pair['refresh']) is None)

Finding Every Consumer That Skips the Check

JWT verification sprawls. The web API checks strictly, the billing worker decodes loosely, and a legacy cron job splits segments by hand. Each consumer makes its own decision about exp, so fleet-wide safety needs an inventory, not assumptions. List every service that accepts tokens before changing anything.

Hunt mechanically. Search for decode, verify, and split calls across repos, flag hand-rolled segment parsing, and record each consumer's leeway and required claims in one table. The stale-replay test then runs against each entry: mint, expire, replay, record 401 or 200. The resulting map shows exactly which services need the strict helper.

Migrate in waves with monitoring. Convert the highest-traffic consumer first, watch 401 rates for honest-client breakage, then proceed down the list. Keep a dashboard of post-expiry accept events per service; it should read zero everywhere and page otherwise.

Lock the win with standards. New services import the shared verifier, CI runs the four negative claim tests, and config changes to leeway need security review. The inventory stays current because the nightly replay proves it, not because someone remembers to update a wiki. Record the decision per consumer so future migrations inherit the map instead of rebuilding it.

Monitoring and Offboarding: Proving Dead Means Dead

Expiry enforcement pays off in offboarding and incident response. When an employee leaves or a password changes, short access plus revoked refresh ends sessions within minutes instead of someday. But only monitoring proves it: log token age at use, alert on post-expiry accepts, and chart the maximum accepted age per service daily.

Build the logout story explicitly. Access tokens can't be individually revoked at scale, so logout revokes the refresh family and lets access die naturally within minutes. Document that window honestly for support and auditors rather than claiming instant global logout. For high-risk events like role removal, pair revocation with a short deny-list of recent access tokens.

Run the numbers after migration. The incident team above watched accepted-token age collapse from 26 days to under 10 minutes on deploy day. Deactivated-account access attempts started returning 401s immediately, and the quarterly audit replay became a non-event.

Keep the evidence flowing: nightly stale replays, per-service accept-age dashboards, and alerts on unknown-kid or future-dated spikes. Dead meaning dead is a property you demonstrate continuously, not a box you check once. Evidence beats memory during audits.