TLDR:Ако искате възможността да отмените маркера в даден момент, да, съхранете го в нещо бързо като Redis.
Един от добре документираните недостатъци на използването на JWT е, че няма лесен начин за отмяна на токен, ако например потребител трябва да излезе или маркерът е бил компрометиран. Отмяната на токен би означавала да го потърсите в някакво хранилище и след това да решите какво да правите по-нататък. Тъй като една от точките на JWT е да се избягват двупосочните пътувания до db, добър компромис би бил да се съхранява в нещо по-малко облагащо от rdbms. Това е перфектна работа за Redis.
Както е предложено в коментарите, добър подход е списъкът да се превърне в черен списък (т.е. списък с невалидни токени). При всяка заявка търсите списъка, за да се уверите, че токенът не присъства в него. Можете допълнително да подобрите пространството в паметта и производителността по време на стъпката за търсене, като използвате вероятностен алгоритъм за съхраняване на маркера. Прост подход е да имате многослойни търсения. Например, можете да имате малък магазин в приложението, който проследява само първите няколко (например 1 до 4) байта от вашите токени в черния списък. Тогава кешът на redis ще проследява малко по-пълна версия на същите токени (например първите 2 до 8 байта). След това можете да съхранявате пълна версия на токените в черния списък, като използвате по-устойчиво решение (файлова система, rdbms и т.н.). Това е оптимистична стратегия за търсене, която бързо ще потвърди, че даден токен отсъства от черния списък (което би било по-честият случай). Ако търсеният маркер съвпада с елемент в черния списък в приложението (тъй като първите му няколко байта съвпадат), тогава преминете към допълнително търсене в хранилището на redis, а след това в постоянното хранилище, ако е необходимо. Някои (или всички) от магазините могат да бъдат внедрени като опити или хеш таблици. Друга ефективна и сравнително лесна за изпълнение структура от данни, която трябва да се вземе предвид, е нещо, наречено Bloom филтър.
Очевидно ще трябва да адаптирате горния подход, ако рутинно поставяте в черен списък милиони дълготрайни токени (което също може да показва, че имате различен проблем).
