<story><title>JWT vs. Opaque Tokens</title><url>https://zitadel.com/blog/jwt-vs-opaque-tokens</url></story><parent_chain><item><author>franky47</author><text>Another drawback for JWTs (when used fully statelessly) is the inability to list active sessions on other devices (which may lead to revocation).&lt;p&gt;That being said, always going to the database for connecting an opaque session token to an identity can quickly become slow, and if those features listed above are not desirable, having a blocklist of revoked JWT IDs in an in-memory cache (like Redis) can bring back some performance benefits.</text></item><item><author>pmontra</author><text>I investigated this issue with a customer recently with a focus on revocation. We concluded that if we have to hit the database to check if a JWT token is still valid we can use a session cookie (or equivalent) and hit the database to get the user, the associated capabilities, etc.</text></item></parent_chain><comment><author>mooreds</author><text>&amp;gt; having a blocklist of revoked JWT IDs in an in-memory cache (like Redis) can bring back some performance benefits.&lt;p&gt;Doing this obviates some of the benefits of JWT&amp;#x27;s statelessness, but for situations where revocation is really important and you can&amp;#x27;t have that few seconds of JWT validity after a user logs out, this totally works.&lt;p&gt;My employer has an article about this topic here: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;fusionauth.io&amp;#x2F;learn&amp;#x2F;expert-advice&amp;#x2F;tokens&amp;#x2F;revoking-jwts&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;fusionauth.io&amp;#x2F;learn&amp;#x2F;expert-advice&amp;#x2F;tokens&amp;#x2F;revoking-jw...&lt;/a&gt;</text></comment>
<story><title>JWT vs. Opaque Tokens</title><url>https://zitadel.com/blog/jwt-vs-opaque-tokens</url></story><parent_chain><item><author>franky47</author><text>Another drawback for JWTs (when used fully statelessly) is the inability to list active sessions on other devices (which may lead to revocation).&lt;p&gt;That being said, always going to the database for connecting an opaque session token to an identity can quickly become slow, and if those features listed above are not desirable, having a blocklist of revoked JWT IDs in an in-memory cache (like Redis) can bring back some performance benefits.</text></item><item><author>pmontra</author><text>I investigated this issue with a customer recently with a focus on revocation. We concluded that if we have to hit the database to check if a JWT token is still valid we can use a session cookie (or equivalent) and hit the database to get the user, the associated capabilities, etc.</text></item></parent_chain><comment><author>Aeolun</author><text>&amp;gt; always going to the database for connecting an opaque session token to an identity can quickly become slow&lt;p&gt;PHP does this every single request. I’ve never had enough users that this became a significant issue (and you probably don’t either)</text></comment>