¿Las mejores prácticas para invalidar JWT al cambiar las contraseñas y cerrar sesión en node.js?

No hay solución a menos que estés golpeando la base de datos. Puede reducir el número de búsquedas a uno en lugar de dos.

Al salir de la contraseña o cerrar sesión, escribe un número de 128 bits generado por un CSPRNG en la fila de ese usuario en su tabla de usuario.

Este CSPRNG forma parte del JWT. En cada acceso, deberá verificar que el número en el JWT coincida con el valor almacenado en la base de datos. Tampoco hay ninguna ventaja de que el MAC se calcule sobre este valor, simplemente lo mantenemos en el JWT para que todo esté en un solo lugar.

Este sorta anula el propósito de usar JWT en primer lugar; también puede usar un token de sesión que esté marcado en el lado del servidor. Sin embargo, la ventaja es que no es necesario mantener las sesiones individuales del lado del servidor, ya que una vez que el JWT caduque, habrá caducado porque no aceptará ninguna fecha de vencimiento en el pasado.

Otra desventaja es que si hay dos sesiones contra el mismo usuario, cerrar una sesión cerrará la sesión. Además, la lógica es más complicada que un sistema administrado del lado del servidor, y la complejidad adicional tiende a reducir la seguridad.

Podría usar un tiempo de vida corto para sus tokens JWT y renovarlos con frecuencia, con un mecanismo para rechazar la renovación de tokens JWT más antiguos. Necesitaría un token de renovación automática en el JWT que podría compararse con algo que almacena en la base de datos. Esto al menos significa que solo se accede a la base de datos para cada ciclo de renovación. Podría establecer eso en 5 minutos, lo que sería mucho menos tráfico que cada transacción de cliente a web.

Sin embargo, piénselo, esta es una solución de mantenimiento muy alto. Solo un porcentaje muy pequeño de sus usuarios realmente solicitará el cierre de sesión de todos los dispositivos.

SOLUCIÓN SUGERIDA:

Si quisiera decirles a los agentes que ya no confíen en unos pocos ID seleccionados, ¿qué haría? Tal vez les pida que vuelvan con usted para actualizar sus registros de una "lista negra" de vez en cuando. Ahora solo tiene un puñado de servicios web "sin estado" que revisan cada x minutos para una actualización. Solo necesita mantener una lista negra de los tokens JWT invalidados de forma proactiva que aún no han caducado.

Creo que encontrará que esta solución se escalará y, por lo general, no es necesario inmediatamente caducar un token. Incluso si lo hiciera, podría ser demasiado tarde para hacer su solicitud para invalidar todos los tokens, así que ¿qué diferencia hay en 60 segundos? Si necesita realizar una acción que sea tan crítica (¿lanzar las armas nucleares?), Tal vez debería pedirle a su usuario final que se vuelva a autenticar en tiempo real para esa.

La mejor práctica de JWT es no usar la base de datos o el caché, la idea de JWT es una verificación de validación sin estado, puede almacenar la ID de usuario dentro de la carga útil del token y utilizarla cuando sea necesario por varios máquinas sin la necesidad de sincronizar un ID de sesión o similar.

Asegúrese de usar ID de usuario largas y aleatorias, de modo que si un atacante logra falsificar un token, solo arriesgará a un usuario y no podrá acceder a otros usuarios, a diferencia de las ID secuenciales.

No creo que hubiera ninguna manera de invalidar el JWT sin consultar la base de datos en cada solicitud.

La mejor idea podría ser emitir los tokens de acceso JWT con un tiempo de caducidad corto, y luego usar tokens de actualización si necesita que se renueve el token de acceso.

De esta manera, aunque no puedes invalidar el token inmediatamente, al menos solo será utilizable hasta que caduque. Cuando se utiliza el token de actualización, su código de autorización puede decidir si se debe emitir un nuevo token de acceso o no.

Sin embargo, solo por curiosidad, ¿por qué necesitaría invalidar el JWT solo por un cambio de contraseña? ¿Hay alguna razón para forzar un cierre de sesión en ese momento? El JWT no incluye la contraseña, por lo que una contraseña modificada realmente no debería tener ningún impacto en el JWT.

La única vez que debería necesitar invalidar al usuario es si sus permisos han sido cambiados o revocados.

El cierre de sesión suele ser una acción iniciada por el usuario, en cuyo caso el cliente simplemente puede borrar / restablecer / eliminar el token JWT que tiene actualmente para el usuario.