tokens - token session

Invalidación de sesión JWT del lado del cliente (3)

He leído mucho sobre JWT y cómo crear sesiones "sin estado" a través de JWT. Lo esencial de lo que entiendo es que debido a la firma y la caducidad, esencialmente puede enviar toda la sesión para que el cliente la guarde y el servidor no tiene que mantener una base de datos para recordar la sesión.

Lo que no entiendo es ¿qué sucede si su usuario necesita cerrar sesión o si necesita invalidar una sesión antes de que caduque?

Técnicamente, podría indicarle al navegador que lo elimine del lado del cliente, pero no puede estar seguro de que esto haya ocurrido realmente. El token en sí mismo es técnicamente válido y si no se siguieron las instrucciones de eliminación, aún podría usarse.

¿Es correcto este entendimiento? Si es así, ¿no es esto un gran error con la administración de sesiones del lado del cliente? ¿Hay algún método para superar esto además de hacer que el servidor almacene la sesión o acortar el tiempo de vencimiento?

Hay varias razones para invalidar un token JWT antes de su hora de vencimiento: cuenta eliminada / bloqueada / suspendida, contraseña modificada, permisos modificados, usuario desconectado por el administrador. Entonces tu pregunta es sobre el tema

Existen varias técnicas para aplicar o combinar según su caso de uso

1) Eliminar el token del cliente del almacenamiento local

2) Lista negra de tokens : almacene tokens que estuvieron entre el cierre de sesión y el tiempo de vencimiento, marque vencidos y verifíquelo en cada solicitud. Use un identificador único jti o incluya la última fecha de inicio de sesión y emitida en iat para eliminar los tokens antiguos

Se necesita almacenamiento en el servidor. Si no espera que se revoquen demasiados tokens, también puede usar una lista negra en memoria. Solo necesita establecer una entrada después de actualizar los datos críticos sobre user y currentTime - maxExpiryTime < lastLoginDate (iat)‌ ‌. La entrada se puede descartar cuando currentTime - maxExpiryTime > lastModified (no se currentTime - maxExpiryTime > lastModified más tokens no caducados). En este caso no es necesario almacenar todo el token. Solo sub , iat y tal vez jti

3) Tiempos de caducidad cortos y rotarlos. Emita un nuevo token de acceso cada pocas solicitudes. Use tokens de actualización para permitir que su aplicación obtenga nuevos tokens de acceso sin necesidad de volver a autenticarse y combinarse con sliding-sessions

Las sesiones deslizantes son sesiones que caducan después de un período de inactividad . Cuando un usuario realiza una acción, se emite un nuevo token de acceso. Si el usuario usa un token de acceso vencido, la sesión se considera inactiva y se requiere un nuevo token de acceso. Este nuevo token se puede obtener con un token de actualización o que requiera credenciales

Otras tecnicas comunes

Permita cambiar la identificación única del usuario si la cuenta se ve comprometida con un nuevo usuario y contraseña
Para invalidar los tokens cuando el usuario cambia su contraseña, firme el token con un hash de su contraseña. Si la contraseña cambia, los tokens anteriores no se verifican automáticamente. Extienda este mecanismo con otro campo de interés para firmar. La desventaja es que requiere acceso a la base de datos.
Cambie el algoritmo de firma para revocar todos los tokens actuales en los principales problemas de seguridad

Echa un vistazo a la invalidación de tokens web JSON

He hecho algunos deberes y parece que el mejor enfoque para implementar la revocación es usar jti (id en Jtw) y una lista negra de id revocado (que se borrará cuando caduque el token). Esto hace que el JTW tenga estado para la única parte de la lista negra.

Las listas negras son una violación sin estado de JWT. Hay muchos esquemas de autenticación que puede usar. JWT se basa en apátridas, por lo que debe usarse de esa manera. Por otro lado, es un esquema de autenticación muy común y si tiene que implementarlo, y si desea que su aplicación (API) sea verdaderamente segura, debe permitirse alguna personalización.

Yo personalmente uso estos dos métodos en mis proyectos (separados o combinados, dependiendo de las necesidades de rendimiento):

Registro de tokens. Registro cada token emitido en mi proyecto, con ID, reclamos, caducidad y lo valido en cada solicitud. Si el token ha caducado, se moverá de este registro al archivo. La caída del rendimiento no es tan horrible.
También agrego a las reclamaciones, además del nombre del usuario, un hash del secreto del usuario (algo así como un token oculto generado automáticamente o una contraseña) que se autoriza en el siguiente paso al cargar el usuario desde dbo. Esto no tiene una caída significativa en el rendimiento porque la consulta para el usuario se realiza de todos modos. El inconveniente es que no puede invalidar el token concreto, solo la sesión de todos los usuarios.