Session lifetime, and what logout actually does

The question worth asking of every JWT-based system: when the user clicks Log out, what actually stops working?

For most implementations the answer is: the cookie in that browser is deleted. That is all. The access token stays valid until exp, the refresh token still works, and the session at the identity provider is still open.

A complete logout is three separate jobs, and knowing which one you are doing is this lesson's whole content:

The second job is the most security-relevant and the most often skipped. Refresh tokens commonly live for days or weeks; if logout does not revoke one, then "log out of all devices" is a button that does nothing.

The third surprises users in a serious way: on a shared computer the user clicks Log out, sees the login page, and believes they are safe — then the next person clicks Log in and walks straight into that account because the IdP session persists. Technically nothing is broken; from the user's side the promise of "log out" has been broken.

And the access token? Not revocable. This is not an oversight to patch but a property of a self-contained token: it is verified by signature, not by a lookup, so there is nowhere to mark "this one is revoked". You have three options, and only three:

1. Short lifetime (5–15 minutes) — accept a window. This is the right answer for most systems.
2. A lookup per request — which discards the benefit of a self-contained token and returns you to server-side sessions.
3. A revocation list — a cache of invalidated jti, checked on every request. It is (2) wearing (1)'s clothes, and it adds a dependency to the authentication path — m1-challenge showed what happens when that dependency dies.