Token Lifetime Scenario Generator
Expiry bugs live at the boundaries: exactly at issue, exactly at expiry, one second either side. And then there is clock skew — a client whose clock runs fast presents a token that looks issued in the future, and rejecting it outright is a common and confusing failure. This lays out every boundary as a test case with the verdict each should produce, derived from the offset rather than written by hand.
What this generator does
Produces checks at every boundary of the validity window — before issue, at issue, mid-life, at expiry, and at both edges of the clock-skew allowance — each with the verdict it should produce.
How to use this tool
- Set the token lifetime and how much clock skew you allow.
- Read each check and the verdict it should produce.
- Note the two skew boundaries at either end.
- Copy the table into a test suite.
Understanding the controls
- Token lifetime (minutes)
- Between 5 minutes and a full day. The boundaries scale with it, so the same eleven cases work at any lifetime.
- Allowed clock skew (minutes)
- How far a client's clock may be out in either direction. Set it to zero and the skew cases collapse into the boundaries, which the table handles rather than duplicating.
Common use cases
- Testing session and token expiry at the boundaries rather than the middle
- Getting clock skew handling right in both directions
- Reviewing whether an expiry check is inclusive or exclusive
- Documenting the intended behaviour of a validity window
- Comparing two lifetime settings side by side
How this generator works
Every verdict comes from one function that maps an offset to a state, so the table cannot disagree with itself. The check re-derives each verdict independently, requires the checks to be in time order, and requires both exact boundaries to be present — since those are the cases the whole suite exists for.
Randomness and fairness
Nothing here is random. A lifetime and a skew allowance determine the whole table, which is why there is no seed.
For how randomness is produced across the whole site, see how Generate Random works.
Limitations and good to know
- Absolute expiry only — sliding sessions that extend on activity behave differently and are not modelled.
- Revocation, refresh tokens and rotation are separate concerns not covered here.
- Times are relative offsets in minutes rather than real timestamps.
- No token is generated; this produces the test cases, not credentials.
- The table is not stored between visits, so a lifetime schedule you intend to implement needs copying out before you leave.
Privacy and your data
The timeline is computed in your browser from the two numbers you enter. Nothing is transmitted or stored.
Related generators
- Permission Matrix GeneratorEvery role, resource and action combination laid out as a checklist, with the denials listed because those are the ones worth testing.
- Access Control Scenario GeneratorPairwise test cases across authentication, role, resource state and origin, with every pair of values proved covered.
- JWT Sample GeneratorGenerate a clearly-fake JWT-shaped sample string — not a valid or usable authentication token.
- Input Validation Scenario GeneratorLength-rule test cases sitting exactly on each boundary and either side, plus the whitespace cases people forget.