TLDR:si desea la capacidad de revocar el token en algún momento, sí, guárdelo en algo rápido como Redis.
Uno de los inconvenientes bien documentados del uso de JWT es que no existe una forma sencilla de revocar un token si, por ejemplo, un usuario debe cerrar sesión o si el token se ha visto comprometido. Revocar un token significaría buscarlo en algún almacenamiento y luego decidir qué hacer a continuación. Dado que uno de los puntos de JWT es evitar viajes de ida y vuelta a la base de datos, un buen compromiso sería almacenarlo en algo menos exigente que un rdbms. Ese es un trabajo perfecto para Redis.
Como se sugiere en los comentarios, un buen enfoque es convertir la lista en una lista negra (es decir, una lista de tokens invalidados). En cada solicitud, busca en la lista para asegurarse de que el token no esté presente en ella. Puede mejorar aún más el espacio de memoria y el rendimiento durante el paso de búsqueda mediante el uso de un algoritmo probabilístico para almacenar el token. Un enfoque simple es tener búsquedas en capas. Por ejemplo, podría tener una pequeña tienda en la aplicación que solo rastrea los primeros bytes (por ejemplo, 1 a 4) de sus tokens en la lista negra. Luego, el caché redis rastrearía una versión un poco más completa de los mismos tokens (por ejemplo, los primeros 2 a 8 bytes). Luego puede almacenar una versión completa de los tokens en la lista negra utilizando una solución más persistente (sistema de archivos, rdbms, etc.). Esta es una estrategia de búsqueda optimista que confirmará rápidamente que un token está ausente de la lista negra (que sería el caso más común). Si un token que se está buscando coincide con un elemento en la lista negra de la aplicación (porque sus primeros bytes coinciden), continúe con una búsqueda adicional en la tienda redis, luego la tienda persistente si es necesario. Algunas (o todas) las tiendas pueden implementarse como intentos o tablas hash. Otra estructura de datos eficiente y relativamente simple de implementar a considerar es algo llamado filtro Bloom.
Obviamente, tendría que adaptar el enfoque anterior si rutinariamente pone en la lista negra millones de tokens de larga duración (lo que también puede indicar que tiene un problema diferente).
