A smart access token (JWT-style) is three parts joined by dots: header.payload.signature. The signature is a keyed hash over the first two parts:
sig = HMAC(secretKey, base64url(header) + "." + base64url(payload))
Each token launched here carries a simplified signature computed the same way (a keyed checksum over its payload). Three independent gates decide whether it is honoured:
- Gate 1 — Signature. The verifier recomputes the checksum over the payload it actually received and compares it to the stored signature. If an attacker tampered with the payload (e.g. escalated a role) without the secret key, the recomputed value can never match —
tamperProbability controls how often this is attempted.
- Gate 2 — Expiry. Every token embeds
exp = issuedAt + TTL. The gate checks now > exp + clockSkew, where a small skew tolerance absorbs harmless clock drift between issuer and verifier (a real, standard JWT practice — RFC 7519 leaves it to the implementation). Too much skew tolerance re-admits tokens that should already be dead, which is exactly what the skew slider lets you feel.
- Gate 3 — Revocation. Signed tokens are stateless, so the only way to kill one early (a logout, a compromised account) is a server-side deny-list keyed by token ID, checked on every request. The admin-revocation slider simulates security ops adding still-valid tokens to that list mid-flight.
A token must clear all three gates, in order, to reach the green platform. The Gate order button lets you swap to Exp→Sig→Rev to demonstrate why real gateways always verify the signature first: checking expiry before authenticity means a tampered token can forge its own exp claim and be judged "not yet expired" before anyone confirms it wasn't rewritten. Failing any gate immediately routes the token into the red quarantine trough with the failing reason recorded.