Developer tools · JWT decoder
Why Short-Lived Access Tokens Matter: JWTs Can't Be Revoked Once Issued
· Why it matters
jwt authentication security
A self-contained token is valid until it expires, whatever happens in between. This post explains the revocation problem, the mitigations available, and why exp is the most important claim you set.
Logout that does not log out — the token that keeps working after the session ended
Logging out can remove a browser’s local copy while a previously issued self-contained token remains acceptable to a verifier that checks only signature and claims. The user experience says “signed out,” but another holder may retain the same compact credential until a policy boundary stops it.
This is not something a decoder can resolve. ToolAcre may show an `exp` value and call it expired relative to the browser clock, yet it has no session store, denylist or issuer connection. Revocation behavior belongs to the architecture that issues and consumes credentials.
Stateless verification and its price — no central list means no central kill switch
Stateless verification allows a resource server to evaluate cryptographic material and claims without querying a central session record for every request. Removing that lookup also removes a natural per-session switch unless another stateful mechanism is added. The trade is architectural, not a property visible in JSON alone.
A token can contain `jti`, but the identifier has no revocation effect until a verifier consults a trusted store or rule. Likewise, a signature can remain mathematically valid after an account is disabled. Application acceptance requires current policy, not only proof that some key signed historical bytes.
Expiry and refresh design can bound exposure, but this repository defines no standard lifetime
Systems often combine a bounded access credential with a separate refresh mechanism, but this repository does not define a universal lifetime or claim that one duration is reasonable. Risk, user experience, detection and infrastructure constraints differ, so this article does not invent token-lifetime guidance.
The principle is narrower: an expiry boundary can limit how long a stolen access token remains useful if the verifier enforces an authenticated `exp`. Refresh processing can then consult more state before issuing another credential. ToolAcre only displays the claims; it performs neither enforcement nor refresh.
Denylists by jti — reintroducing state for the cases that need immediate revocation
A denylist keyed by `jti` can reintroduce an immediate decision point for selected tokens. That requires a unique identifier, trusted insertion path, storage availability and verifier lookup policy. Merely decoding a `jti` does not show uniqueness or prove that a store contains it.
The same state can support account-wide or session-specific invalidation depending on design. It also restores operational dependencies that stateless verification avoided. Evaluate cache failure, retention and propagation explicitly rather than presenting a denylist as a free toggle.
Introspection and key rotation — asking the issuer, or invalidating everything at once
Introspection asks an authority for current token state, turning acceptance into an online decision. Key rotation can stop verification under removed keys, but it may invalidate many tokens at once and is not a precise substitute for session revocation. These mechanisms solve different operational problems.
ToolAcre knows none of their current state. A decoded issuer, key identifier or expiry can help locate relevant records, but the panel never contacts an issuer and never verifies a signature. Use authoritative service telemetry to learn whether a token is active, revoked or rejected.
Worked example: calculate the declared interval without judging whether it is reasonable
For a controlled example, subtract numeric `iat` from `exp` to calculate the interval claimed by the payload. If `iat` is 1,717,243,200 and `exp` is 1,717,246,800, the difference is 3,600 seconds. ToolAcre also displays each value as an ISO instant.
The arithmetic does not judge the interval. It cannot prove either claim was issued by the expected party, and the repository supplies no recommended lifetime. Compare the authenticated values with your documented policy only after verification, then test how logout and revocation state affect real requests.
What this does not cover — refresh token storage and rotation, which are their own design problem
Refresh-token storage, rotation and replay detection are separate design subjects. A refresh token may be opaque, may have different handling and should not be sent to a resource API merely because an access token is rejected. This decoder is specifically shaped around three-part JWS-like input.
Do not paste refresh credentials into it. If a refresh token is opaque, there may be nothing useful to decode; if it is structured, disclosure still creates credential risk. Diagnose issuance flows using the provider’s trusted tooling and logs.
Expiry is one lever among verification, revocation state and credential design
Expiry is useful, but not a complete revocation strategy and not a decoder verdict. The consuming system must authenticate the token, enforce time and audience policy and consult any revocation state its architecture requires. Each mechanism has availability and operational consequences.
Use ToolAcre only to observe the values in a safe token. It can answer “what interval does this payload claim?” It cannot answer “should this request be accepted now?” or “is this session revoked?” Those questions belong to trusted services.