Sessions vs JWT authentication state

What it means

A token format and an application's state policy are separate choices. A session identifier can point to server-held state; a signed JWT can carry claims for local verification. Using JWTs does not itself require every verifier to be local-only, and using server sessions does not remove the need for expiry and secure credential handling.

This comparison isolates one question: after authentication, which evidence can change the decision to permit continued use? The labels “local-only JWT” and “central session lookup” name the two declared designs in the Simulation—not every implementation of either approach.

Try it

Simulation: use synthetic values only; this scene does not authenticate a real credential. Start with the baseline below, then change Age (minutes) from 10 to 30. Inspect the updated result and why it changed. Select Compare with baseline to view the baseline and current outcomes together. Reset restores the starting inputs and clears errors and the comparison.

Within declared lifetime. Age 10 minute(s), expiry boundary 30 minute(s); equality is expired under the zero-leeway fixture. This design performs no central lookup: revocation and lookup fields are not evaluated. Lifetime alone does not prove all authentication checks pass.

Keep Validation design = local-only JWT, Lifetime (minutes) = 30, Central record says revoked? = no and Central lookup result = available. Change only Age (minutes) to 30.

Reset restores Validation design = local-only JWT, Age (minutes) = 10, Lifetime (minutes) = 30, Central record says revoked? = no and Central lookup result = available. It removes input errors and clears the comparison. There is no running clock or stored event history to reset. Your independently chosen open or closed states for FAQ answers and About this model stay unchanged.

How it works

The model first checks time. For valid inputs, Age ≥ Lifetime produces Rejected: expired in either design. That test takes precedence: rejection at expiry does not imply that a central record was successfully retrieved or evaluated.

When Age is less than Lifetime, the selected design determines the next source of evidence. In local-only JWT mode, there is no central lookup. Changing a central field therefore cannot change this branch's result: those fields are not evaluated, even though their supplied values remain visible in the input table. In central session lookup mode, continued use depends on the modeled central record.

At Age = 10 minutes and Lifetime = 30 minutes, the comparison is:

The second row exposes the causal difference. Remaining lifetime is identical, but only the central-lookup branch evaluates the revocation record. The record denies continued use despite that remaining lifetime; the local-only branch has no evidence path by which to learn the denial.

The last row is not proof of either an active or a revoked session. With a required lookup unavailable, the model cannot establish current central state, so it reports unknown rather than using the selected revocation value as though a record had been retrieved. The missing evidence is an available central-record result.

Worked example

This is a synthetic baseline, not a captured request or production observation.

The intermediate test is 10 is less than 30, so the expiry rule does not reject. The selected local-only branch then ends without consulting central state, producing Within declared lifetime.

The displayed “available” and “no” values are supplied inputs, not evidence of a lookup this branch performed. That distinction matters: the result would be the same in this mode if those central fields changed while age and lifetime stayed fixed.

What changes when the condition changes

Change Age (minutes) to 30. Keep Validation design = local-only JWT, Lifetime (minutes) = 30, Central record says revoked? = no and Central lookup result = available.

The result is Rejected: expired. Age 30 minute(s), expiry boundary 30 minute(s); equality is expired under the zero-leeway fixture. The declared local time rule is sufficient for rejection; no successful central lookup is implied.

Only age changed. The earlier condition, 10 is less than 30, became 30 ≥ 30, so the expiry test now ends the evaluation before the choice of validation design matters. An unrevoked central record would not extend this declared lifetime.

In practice

For an application you own or are authorized to assess, start with a read-only review of its authentication design. Identify where authenticated state is stored, which evidence each verifier consults, and what must happen after a session or credential is invalidated. This comparison does not require changing a deployment or testing another person's credentials.

Use your requirements to choose the design. If a verifier must consult the central invalidation record before permitting continued use, the central-lookup design makes that dependency explicit. If verification must proceed without that lookup, a local-only design removes that particular dependency—but cannot also promise awareness of an uncommunicated central revocation. A short lifetime limits the declared time window; it does not make the verifier aware of a revocation event during that window. Neither observation establishes which design is faster or more reliable in your deployment.

Check the full validation contract separately. For JWTs, RFC 8725 sections 3.1, 3.8 and 3.9 address algorithm, issuer and audience requirements. Decoding a payload or passing the lifetime test is not sufficient. For server sessions, identify the application's expiration and invalidation rules and the record consulted on each request.

STOP if a required check is unavailable or its outcome is unclear. Do not turn that missing evidence into an authenticated-session verdict or silently bypass a required lookup. Use the application's explicit failure policy and obtain the missing evidence. Even a modeled unrevoked record does not establish permission to perform a particular action; authorization is a separate check.

Limits and unknowns

The scene assumes a previously authenticated token or session. It processes no real token, signature, key, cookie, session store or account. It does not implement cryptographic verification, issuer or audience checks, clock-skew allowance, storage checks or account checks. Do not enter credentials or use its results to approve a real request.

Age is a supplied number, not a running clock. The exercise uses a zero-leeway expiry boundary and does not measure lookup latency, revocation propagation, service availability or security. “Within declared lifetime” establishes only that the modeled expiry test did not reject; it is not an authentication verdict.

Use Age from 0–1440 minutes and Lifetime from 1–1440 minutes. If an input is invalid, the scene shows an error instead of retaining a calculated outcome from an earlier valid input. Correct the input or use Reset. “Central state unavailable” is a different condition: the inputs can be valid while the required evidence remains insufficient.

The initial example and explanations remain readable without JavaScript. Interactive controls require JavaScript; the scene performs no network request or system change.

What to carry forward

Choose where authentication state lives and how verifiers learn that it has changed—not just a credential format. A local-only design cannot act on a revocation event it never receives; a design requiring a central record needs a defined response when that record is unavailable. Your next useful step is to identify those evidence paths in your application before choosing either design.