JWT is not synonymous with a session. RFC 7519 defines a JSON Web Token as a compact format for representing claims between parties. It can be used as a credential inside an authenticated session, for example as an access token, but the JWT standard does not by itself define login, session duration, logout, renewal, or revocation. Those rules belong to the authentication and authorization architecture.
The practical consequence matters: a JWT remaining valid until its expiration time does not mean the application must consider the user's session active until that instant, and a user clicking "log out" does not automatically invalidate every copy of a JWT that has already been issued. To understand the full lifecycle, four concepts need to be separated: token, session, expiration, and revocation.
JWT, session, access token, and refresh token are not the same thing
| Element | What it represents | Who normally validates or uses it | What it does not solve by itself |
|---|---|---|---|
| JWT | A format for carrying a set of claims, protected by JWS or JWE as applicable. | The party receiving the token and applying the validation rules for the profile in use. | It does not define session policy, logout, storage, or revocation. |
| Authenticated session | The logical state in which the application recognizes an authenticated identity and applies a lifecycle. | The application, authorization server, and other components involved in authenticated state. | It does not require JWT. It can use an opaque identifier linked to server-side state. |
| Access token | A credential used to access protected resources. In OAuth 2.0, its format can vary. | Resource server or API. | It is not necessarily a JWT and should not be confused with a refresh token. |
| Refresh token | A credential used to obtain new access tokens when the current one expires or otherwise becomes invalid. | Authorization server. RFC 6749 says it is not sent to resource servers. | It does not directly authorize a normal API call, and issuing one is optional. |
This distinction also avoids a misleading phrase: "JWT authentication" can describe an architecture that uses JWTs as credentials, but JWT is the token format, not the complete authentication protocol or the session itself. A system can have a session with a cookie and opaque identifier, a JWT access token, an opaque access token, or different combinations.
What JWT expiration actually does
The exp claim in RFC 7519 identifies the time on or after which the JWT must no longer be accepted for processing. The specification allows a small amount of leeway for clock differences, and use of exp is optional in the general standard, although profiles and applications commonly impose their own requirements.
This mechanism answers one specific question: "is this token still inside the time window in which it may be accepted?". By itself, it does not answer "is the user still logged in?", "did the user click log out?", "was the account blocked?", "was the password changed?", or "did an administrator terminate all sessions?". Those decisions require additional state or signals in the architecture.
Imagine a JWT access token that is valid for ten minutes. If the user logs out in minute two and the API checks only signature, issuer, audience, and exp, a copy of that token that has already been obtained may continue to be accepted until the end of the window. To stop its use before expiration, the system needs some revocation mechanism, state check, or session credential whose validity can be ended on the server.
The architectural flow: login, access token, expiration, refresh, and revocation
- Login: the application authenticates the user and establishes the state required by the design, which may include a server-side session, token issuance, or both.
- Access token: the client receives a credential for accessing the API. If it is a JWT, the API validates not only time but also the cryptographic rules and claims required by the profile.
- Normal use: while the token is acceptable, it can authorize calls within the privileges, audience, and other restrictions that were established.
- Expiration: when exp is reached, that JWT is no longer accepted. This ends the usefulness of that specific credential, not necessarily the entire authenticated experience.
- Refresh: if the architecture uses a refresh token and it remains valid, the client can request a new access token from the authorization server without immediately repeating the full login.
- Revocation or logout: the architecture invalidates the relevant session or credentials on the server. Depending on the design, this may include revoking refresh tokens, marking identifiers invalid, ending a server-side session, or checking revocation state.
Expiration and logout are therefore different events. Expiration is a time-based rule for accepting a credential. Logout is a session-lifecycle action that should cause appropriate invalidation of the state or credentials that would otherwise allow authenticated use to continue.
Where the refresh token fits
In OAuth 2.0, refresh tokens are credentials used to obtain new access tokens. They often live longer than the access token and therefore create a different risk: if a refresh token is stolen and remains usable, an attacker may be able to obtain new credentials even after older access tokens expire.
For that reason, a refresh token should not be treated as merely "a JWT that lasts longer". Its format is separate from the function it performs. RFC 6749 notes that it is usually opaque to the client, and RFC 9700, the current Best Current Practice for OAuth 2.0 security, requires public clients to protect against replay through sender-constrained refresh tokens or refresh token rotation.
With rotation, each successful use produces a new refresh token and invalidates the previous one, while the server retains enough relationship information to detect improper reuse. This deliberately reintroduces state at the authorization server, which is a security and lifecycle-control choice, not a failure of the model.
Revocation: how to end validity before the clock does
Revocation means making a credential or authorization unusable before it would become invalid only because of time. Different strategies exist, and each changes the balance among simplicity, scalability, and immediate control.
Server-side stateful session
The client keeps an identifier, commonly in a cookie, and the server looks up a session record. Logout can invalidate that record immediately. The advantage is centralized control; the cost is storing and consulting session state.
Short JWT access token without revocation checks
The API can validate the token locally, reducing dependence on a central lookup for every request. In exchange, immediate revocation is limited: a copied token generally remains usable until it expires. Shortening the access-token lifetime reduces that window, but does not make it zero.
JWT with a revocation list or status check
The application can maintain revocation state, for example associated with a token identifier, or consult a status mechanism. OWASP describes a denylist as one way to address the invalidation problem in JWT architectures, while also warning that implementation must account for details such as appropriate identifiers and strict validation.
Revocation in OAuth 2.0
RFC 7009 defines an endpoint through which the client tells the authorization server that a token is no longer needed. The specification requires support for refresh-token revocation and recommends support for access-token revocation. The exact effect can depend on token type and server policy.
Key rotation is not an individual logout mechanism
Rotating or withdrawing a signing key can invalidate many tokens at once and is useful for cryptographic key management or incident response. As a logout strategy for one user, however, it is too broad because it affects every token that depends on that key.
Trade-offs of common designs
| Design | Central state | Immediate logout | Main advantage | Main cost |
|---|---|---|---|---|
| Cookie + server-side session | Yes | Direct, by invalidating the session | Simple lifecycle control | Session storage and lookup |
| Self-contained JWT access token, no revocation | Little during access-token validation | Not for an already issued copy unless additional measures exist | Local, decoupled validation | Window until expiration |
| Short JWT + server-controlled refresh token | Yes in the refresh flow | Can block new renewals; current access tokens still depend on their window or additional revocation | Combines short access tokens with a renewable session | More components and policies for rotation, storage, and revocation |
| JWT + status check or denylist | Yes | Can be fast depending on the check | Revocation before exp | Loses part of the benefit of fully local validation and requires state management |
There is no universally best design. An internal API, a banking application, a traditional web application, and a distributed ecosystem have different requirements for risk, latency, scale, and revocation. The architectural decision should begin with the desired lifecycle and relevant threats, not with a preference for JWT as a technology.
Validating a JWT means more than checking expiration
Even when exp is correct, a JWT should not be accepted merely because it has not expired. RFC 8725 requires appropriate validation of algorithms and cryptographic operations and instructs applications to validate issuer and audience when applicable. Specific profiles may also require token type, subject, not-before, identifiers, and other claims.
Confidentiality is another important point. A JWT protected by a signature or MAC can have integrity without its contents being secret. Encryption is a separate property. An application therefore should not assume that information placed in a signed JWT is hidden from the client or from anyone who obtains the token.
Questions that help diagnose the architecture
- "If the JWT expired, was the user logged out?" Not necessarily. The access token expired, but a session or refresh token may still allow another one to be issued.
- "If I delete the token from the browser, did I log out?" That removes the local copy, but does not guarantee that other copies already obtained have been invalidated on the server.
- "Does a refresh token need to be a JWT?" No. The refresh-token function does not require JWT, and OAuth permits its representation to be opaque to the client.
- "Does JWT make everything stateless?" Not by definition. Revocation, refresh tokens, replay detection, administrative sessions, and other policies may require server-side state.
- "Does a short access token solve revocation?" It limits the exposure window, but does not provide immediate invalidation by itself.
The safer mental model
Think of JWT as a standardized envelope for claims that can be used by a larger architecture. exp controls the temporal validity of that envelope; the access token controls access to resources according to its scope and profile; the refresh token allows new credentials to be requested; and the session defines the logical authentication lifecycle the application wants to maintain.
When logout and revocation matter, the architecture needs a control point capable of saying "this session or authorization is no longer valid", even if some credential has not yet reached its expiration time. That separation between token format and lifecycle is what prevents JWT from being treated as if it were, by itself, a complete session system.
Sources and references
- IETF RFC 7519: JSON Web Token (JWT)
- IETF RFC 8725: JSON Web Token Best Current Practices
- IETF RFC 6749: The OAuth 2.0 Authorization Framework
- IETF RFC 7009: OAuth 2.0 Token Revocation
- IETF RFC 9700: Best Current Practice for OAuth 2.0 Security
- OWASP Cheat Sheet Series: Session Management
- OWASP Cheat Sheet Series: JSON Web Token
