JWT Auth and Session Store: Does Expiring a JWT Token Also Invalidate the Corresponding Session?
0 reputation · 15 Mar 2020, 07:35 UTC
0 reputation · 15 Mar 2020, 07:35 UTC
Determine whether an expired JWT token processed by the AdonisJS Auth provider automatically invalidates the corresponding session store entry when both JWT and session authentication are enabled in an AdonisJS v5 application.
The JWT provider validates the exp claim and returns a 401 on expiry, while the session provider relies on the session's maxAge to invalidate sessions. The documentation states that these providers operate independently, but it is unclear if any built‑in hook or event ties JWT expiry to session cleanup, leaving developers to decide whether manual invalidation is required to enforce least‑privilege access.
Does the JWT provider trigger any session invalidation when an expired token is detected? Is there a built‑in mechanism or event that allows the session store to be cleared upon JWT expiry, or must developers implement custom middleware or listeners to achieve synchronized privilege revocation?
32775 reputation · 15 Mar 2020, 17:20 UTC
No. In AdonisJS v5 an expired JWT is rejected by the JWT provider with a 401, but that rejection does not automatically invalidate or delete the corresponding server-side session store entry. The JWT provider and the session provider operate independently and there is no built-in hook or event that ties JWT expiry to session cleanup.
If JWTs are used purely stateless, there is no server session to invalidate. The token is self-contained and expiry is only a client-side presentation problem.
If a session store is maintained alongside JWTs, token expiry and session expiry can diverge. The session can remain present and usable by the application until its own TTL elapses or it is manually removed, even after the JWT is no longer accepted. This creates orphaned session data and a potential least-privilege gap.
One diagnostic detail that changes the recommendation: Is the JWT stored inside the session or used as a standalone bearer token for a separate API guard? If it is standalone, session invalidation on JWT expiry is not relevant. If the JWT is issued per session and you expect expiry to end the session, explicit sync is required.
Use comments to ask for clarification. Post a solution as an answer.
4,630 reputation · 15 Mar 2020, 11:41 UTC
To expand on the independence of these providers, it is important to note that in AdonisJS v5, guards are designed to be mutually exclusive per request based on the configured auth middleware. If a request is processed by the JWT guard and fails due to an expired exp claim, the execution flow typically terminates with a 401 response before the session guard is even evaluated.
This creates a specific edge case for developers implementing "hybrid" authentication: a user might have an expired JWT but still possess a valid session cookie. Because the JWT guard does not trigger a session cleanup, the user remains authenticated via the session provider if the request is subsequently routed through a session-based guard.
To verify this behavior in your environment, you can perform the following test: