<story><title>JWT should not be your default for sessions</title><url>https://evertpot.com/jwt-is-a-bad-default/</url></story><parent_chain><item><author>rsj_hn</author><text>JWTs are good for API tokens, not end users. If you use JWTs for your cookies&amp;#x2F;session state, then you&amp;#x27;ll still need to maintain a table of valid JWTs and expire them when the user logs out, and thus you will not be able to use JWTs as they were intended to be used, which is as stateless tokens.&lt;p&gt;Most security auditors&amp;#x2F;certifications&amp;#x2F;compliance requirements do not consider even a 5 minute lag acceptable for user driven logout. The definition of logout is that when the user presses the logout button, all the session data is invalidated server-side during roughly the time it takes for a request&amp;#x2F;response roundtrip.&lt;p&gt;Thus there is no benefit to using a non-opaque high entropy string for user sessions, even though there is a good benefit to using JWTs as API tokens for back-end services (esp. microservices) that do not have browser logout requirements.</text></item></parent_chain><comment><author>lmm</author><text>I&amp;#x27;ve seen plenty of people make the equal and opposite wasteful mistake: they insist on using a shared state store so that logins can be properly revoked, then they notice that every server looking up the session in this shared store on every request is having a significant performance impact, so instead they have the server cache sessions locally for 5 minutes (or even longer).</text></comment>
<story><title>JWT should not be your default for sessions</title><url>https://evertpot.com/jwt-is-a-bad-default/</url></story><parent_chain><item><author>rsj_hn</author><text>JWTs are good for API tokens, not end users. If you use JWTs for your cookies&amp;#x2F;session state, then you&amp;#x27;ll still need to maintain a table of valid JWTs and expire them when the user logs out, and thus you will not be able to use JWTs as they were intended to be used, which is as stateless tokens.&lt;p&gt;Most security auditors&amp;#x2F;certifications&amp;#x2F;compliance requirements do not consider even a 5 minute lag acceptable for user driven logout. The definition of logout is that when the user presses the logout button, all the session data is invalidated server-side during roughly the time it takes for a request&amp;#x2F;response roundtrip.&lt;p&gt;Thus there is no benefit to using a non-opaque high entropy string for user sessions, even though there is a good benefit to using JWTs as API tokens for back-end services (esp. microservices) that do not have browser logout requirements.</text></item></parent_chain><comment><author>Rapzid</author><text>&amp;gt; maintain a table of valid JWTs and expire them when the user logs out&lt;p&gt;Wouldn&amp;#x27;t you just need a list of logged-out JWTs? And maintain entries until the JWT would have expired?.&lt;p&gt;And that&amp;#x27;s if you really cared. Some people would be fine with the client and server participating in the log out and a low-ish JWT expiry.</text></comment>