What I do: I use tokens (rather than cookies), but I don't use JWT, for some of the reasons listed in the post, such as "can't expire" and "data goes stale". In

What I do: I use tokens (rather than cookies), but I don't use JWT, for some of the reasons listed in the post, such as "can't expire" and "data goes stale". Instead, after authenticating a user, I issue a long piece of random (256 bits of random packed into a base64 string) to the user. I use the same string as a redis key whose value is the actual user ID of the authenticated user. That way the front end can pass the token to the back end, I can authenticate and authorize using the redis data (I could store more data in redis, but instead I hit postgres for any other data about the user, such as admin roles, when needed during the authorization process). It's true that this doesn't make you invincible to CSRF or XSS - any attacker who goes through the trouble and gets access to the token via MITM (although I only use HTTPS, that's not a guarantee) or by injecting javascript in the webapp itself (through user-editable content from a malicious user), that attacker suddenly has full access to the user's account. Still, it's a pretty reasonable way to deal with session problems. I also set expiry timeouts on these tokens and can delete them manually if a user wants to end all sessions (say on password change). Deleting by value match isn't super-straightforward in redis, but it's also possible with a bit of LUA.