JWT Challenge Week 1: The Token That Time Forgot

This is the full write-up for Cyberway's first weekly JWT challenge. Each week we publish a public sample JWT with a deliberate security or lifetime flaw. Your job: load the token, investigate, and identify what would cause a production verifier to reject it. The sample is educational — not a real credential — and nothing you do is stored on a server.

What the weekly challenge is

The challenge mode lives inside the JWT Decoder. When active, a prompt and answer field appear above the token input. Expiry badges and security callouts stay hidden until you submit a correct answer — so the puzzle does not spoil itself while you investigate.

We built this because reading about exp is different from finding a bad exp in a real token structure. The challenges reinforce habits you need in production incident response.

Load the challenge

1. Open the JWT Decoder or go directly to /?challenge=current.
2. Click Load challenge (or the challenge loads automatically from the URL).
3. The sample token appears in the input field — still 100% client-side.
4. Decode the token and inspect header and payload before submitting an answer.

Click Exit challenge anytime to return to a clean decoder state.

The token

Week 1's sample token (from Cyberway's challenge fixture):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJjaGFsbGVuZ2UtdXNlciIsImlzcyI6ImN5YmVyd2F5LmRldiIsImlhdCI6MTcwMDAwMDAwMCwiZXhwIjoxNzAwMDAzNjAwLCJqdGkiOiJjdy1jaGFsbGVuZ2UtMSJ9.challenge

Header (decoded)

{
  "alg": "HS256",
  "typ": "JWT"
}

Standard HMAC-SHA256 header. Nothing unusual here — the flaw is not in the algorithm.

Payload (decoded)

{
  "sub": "challenge-user",
  "iss": "cyberway.dev",
  "iat": 1700000000,
  "exp": 1700003600,
  "jti": "cw-challenge-1"
}

exp is a NumericDate in Unix seconds, defined in RFC 7519 §4.1.4. Compliant libraries must reject tokens whose exp is before the current time.

What you should notice

Focus on the time claims:

• iat (issued at): 1700000000 → November 14, 2023, 22:13:20 UTC
• exp (expires): 1700003600 → November 14, 2023, 23:13:20 UTC — exactly one hour later

Both timestamps are years in the past relative to today. A compliant verifier compares current Unix time to exp and rejects the token immediately.

After you submit a correct answer (exp, expired, expiry, or similar), Cyberway unlocks the Expiry badge showing the token as expired and reveals security callouts explaining why.

Verifier order: exp before signature

Many JWT libraries check time claims before or independent of signature verification. From a security standpoint, an expired token is invalid regardless of whether the HMAC is correct — there is no legitimate use case for accepting it. See the OWASP JWT Cheat Sheet for validation ordering guidance.

In incident triage, if you see JWTExpired in logs, do not assume the signing key is wrong. Check exp first. See JWT expired token errors for production fixes.

Lesson: Decode is not authenticate. A token can have a valid-looking structure and a plausible signature story but still be unusable because of time claims.

Solution walkthrough

Accepted answers include: exp, expired, expiry, expired exp, token expired, exp expired.

The solved summary: exp is in the past — the token is expired.

Why this matters for production:

• Mobile apps caching tokens past exp cause sudden 401 storms.
• Clock skew between issuer and verifier can mimic expiry errors — but here exp is unambiguously historical.
• Monitoring should alert on rising JWTExpired rates, not only signature failures.

Lessons for production

1. Always include exp on access tokens with a lifetime appropriate to risk.
2. Log expiry separately from signature failures in metrics.
3. Test refresh flows — clients must not retry the same expired JWT indefinitely.
4. Use the decoder to inspect tokens from support tickets before blaming "auth is broken."

Common wrong answers

If you guessed signature or alg first, reconsider: the header declares a normal algorithm and the challenge focuses on lifetime. Week 1 is intentionally about exp — future challenges cover other flaw classes (weak secrets, claim mismatches, and more).

Compare your investigation steps with the JWT expired token error guide for the same claim explained in a production context.

Sharing your approach

If you solved the challenge differently — for example by converting exp to a calendar date first — the answer still converges on lifetime. What matters is that you inspected claims before assuming a signature bug. That habit transfers directly to on-call work.

After solving, use Exit challenge to return to a blank decoder, then try pasting your own test tokens from the JWT Generator to compare a valid future exp against the challenge sample. The contrast makes the lifetime check tangible.

Teaching teams to read exp before signature errors reduces mean time to diagnose auth incidents. Add this challenge to onboarding for backend engineers who touch API gateways or auth middleware — it takes five minutes and sticks better than a slide deck. The skills transfer directly: production logs often show JWTExpired long before anyone questions the signing key. Keep a link to this write-up in your team wiki next to the decoder.

Try the next one

New challenges appear on the decoder over time. Browse more guides from the blog or read the Complete JWT Guide for the full picture on claims and verification.