Back to Learning
Security · Zero TrustIntermediate

Zero Trust: JWT Access & Token Expiry

A freshly issued token is rejected as expired. Compare the claims against the host clock, live, right below.

Interactive simSecurityZero TrustIdentity

Symptom

Never trust, always verify: explicit auth, least-privilege endpoints and short-lived JWTs that fail closed the moment they expire.

Your mission

Inspect, recover, then verify

Format

Linux shell

Zero Trust: The Token That Was Already Expired

Investigate before you configure.

Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.

Observe the symptom and link state.

Diagnose by comparing the protocol evidence.

Verify the expected device state and confirm the original symptom is resolved.

Console access: Linux

This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.

Need a hint?

Reveal the root cause when you're ready.

Try the investigation first, then use this as your escape hatch, not a dead end.

Locked

Sign up with your email to open Zero Trust: JWT Access & Token Expiry, free. You get the root cause and the full step-by-step fix.

No spam. The fix lands in your inbox too. Signing up includes 4 guided labs free, tracked against your email. After that, the Learning Pass unlocks every remaining lab.

Lab debrief

Turn the session into a repeatable troubleshooting pattern.

Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.

The problem

A user logs in, gets a token and reaches the protected API fine. A few minutes later, without logging out, every protected call starts returning 401, and a service-to-service request that worked at login now fails too.

What you'll practice

  • Authenticate explicitly against the identity service and obtain a JWT
  • Separate public from protected endpoints (least privilege)
  • Inspect JWT claims (exp, iat, iss, aud) and validate them
  • Handle short-lived tokens with a refresh before expiry
  • Diagnose 401s caused by token expiry or clock skew (assume breach)

The topology

An identity service issues JWTs, a web application validates them on every protected request, and a datastore holds users and audit logs. Public endpoints need no token; protected ones verify explicitly, so the trust boundary sits at each hop rather than only at login.

Commands to run yourself

The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.

Decode the token without verifying
node decode.mjs $TOKEN
Verify the token
node verify.mjs $TOKEN
Compare the two clocks
chronyc tracking

Topology diagram

Fact-checked references

The commands and behaviour in this lab were checked against these primary references.

Frequently asked

Is this Cisco-specific?

The principles (verify explicitly, least privilege, assume breach) are the same ones Cisco's Zero Trust and ISE-based access enforce. Here you exercise them hands-on against a real token flow.

Are the tokens really short-lived?

Yes. Tokens expire in minutes by design, so you see fail-closed behaviour and refresh handling for real, not in theory.

Ready to run this lab yourself?

No setup, no image sourcing. Book a session or ask for a live demo.