TLDR:Pokud chcete možnost v určitém okamžiku token zrušit, ano, uložte jej do něčeho rychlého, jako je Redis.
Jednou z dobře zdokumentovaných nevýhod používání JWT je, že neexistuje jednoduchý způsob, jak zrušit token, pokud například uživatel potřebuje být odhlášen nebo byl token kompromitován. Zrušení tokenu by znamenalo vyhledat ho v nějakém úložišti a pak se rozhodnout, co dál. Vzhledem k tomu, že jedním z bodů JWT je vyhnout se zpátečním cestám do db, dobrým kompromisem by bylo uložit jej do něčeho méně náročného než rdbms. To je pro Redis perfektní práce.
Jak bylo navrženo v komentářích, dobrým přístupem je udělat ze seznamu černou listinu (tj. seznam zneplatněných tokenů). Při každé žádosti vyhledáte seznam, abyste se ujistili, že v něm není přítomen token. Během kroku vyhledávání můžete dále zlepšit paměťový prostor a výkon pomocí pravděpodobnostního algoritmu k uložení tokenu. Jednoduchý přístup je mít vrstvené vyhledávání. Můžete mít například malý obchod v aplikaci, který sleduje pouze prvních pár (např. 1 až 4) bajtů vašich tokenů na černé listině. Potom by mezipaměť redis sledovala o něco kompletnější verzi stejných tokenů (např. prvních 2 až 8 bajtů). Poté můžete uložit plnou verzi tokenů na černé listině pomocí trvalejšího řešení (systém souborů, rdbms atd.). Toto je optimistická vyhledávací strategie, která rychle potvrdí, že na černé listině chybí token (což by byl častější případ). Pokud se vyhledávaný token náhodou shoduje s položkou na černé listině v aplikaci (protože se jeho prvních pár bajtů shoduje), přejděte k dalšímu vyhledávání v obchodě redis a v případě potřeby v trvalém obchodě. Některé (nebo všechny) obchody mohou být implementovány jako pokusy nebo hashovací tabulky. Další efektivní a relativně snadno implementovatelnou datovou strukturou, kterou je třeba zvážit, je něco, čemu se říká Bloomův filtr.
Je zřejmé, že byste museli přizpůsobit výše uvedený přístup, pokud běžně uvádíte na černou listinu miliony dlouhotrvajících tokenů (což může také znamenat, že máte jiný problém).