Autenticación: uso de JWT frente a sesión

Resuelto Pourya8366 asked hace 7 años • 7 respuestas

¿Cuál es la ventaja de utilizar JWT sobre sesiones en situaciones como la autenticación?

¿Se utiliza como un enfoque independiente o se utiliza en la sesión?

Pourya8366 avatar Apr 17 '17 20:04 Pourya8366
Aceptado

JWT no tiene ningún beneficio sobre el uso de "sesiones" per se. Los JWT proporcionan un medio para mantener el estado de la sesión en el cliente en lugar de hacerlo en el servidor.

Lo que la gente suele decir cuando pregunta esto es "¿Cuáles son los beneficios de usar JWT sobre el uso de sesiones del lado del servidor ?".

Con las sesiones del lado del servidor, tendrá que almacenar el identificador de la sesión en una base de datos o mantenerlo en la memoria y asegurarse de que el cliente siempre acceda al mismo servidor. Ambos tienen inconvenientes. En el caso de la base de datos (u otro almacenamiento centralizado), esto se convierte en un cuello de botella y algo que hay que mantener; esencialmente, una consulta adicional que debe realizarse con cada solicitud.

Con una solución en memoria, usted limita su escalamiento horizontal y las sesiones se verán afectadas por problemas de red (clientes en itinerancia entre Wifi y datos móviles, reinicio de servidores, etc.).

Mover la sesión al cliente significa que se elimina la dependencia de una sesión del lado del servidor, pero impone su propio conjunto de desafíos.

  • Guardar el token de forma segura.
  • Transportarlo de forma segura.
  • A veces, las sesiones JWT pueden resultar difíciles de invalidar.
  • Confiando en el reclamo del cliente.

Estos problemas son compartidos tanto por los JWT como por otros mecanismos de sesión del lado del cliente.

JWT, en particular, aborda el último de ellos. Puede resultar útil comprender qué es un JWT:

Es un poco de información. Para las sesiones de usuario, puede incluir el nombre de usuario y la hora en que caduca el token. Pero es posible que sea cualquier cosa, incluso el ID de la sesión o el perfil completo del usuario (aunque no hagas eso). Tiene una firma segura que evita que partes malintencionadas generen tokens falsos (necesita acceso a la clave privada del servidor para firmarlos y puede verificar que no fueron modificados después de firmarlos). Los envía con cada solicitud, tal como Authorizationse enviaría una cookie o un encabezado. De hecho, normalmente se envían en el Authorizationencabezado HTTP, pero usar una cookie también está bien.

El token está firmado y así el servidor puede verificar su origen. Supondremos que el servidor confía en su propia capacidad para firmar de forma segura (debe utilizar una biblioteca estándar: no intente hacerlo usted mismo y asegure el servidor adecuadamente).

En cuanto a la cuestión del transporte seguro del token, la respuesta suele ser enviarlo a través de un canal cifrado, normalmente httpS.

Con respecto al almacenamiento seguro del token en el cliente, debes asegurarte de que los malos no puedan acceder a él. Esto (principalmente) significa evitar que JS de sitios web malos lea el token para enviárselo de vuelta. Esto se mitiga utilizando las mismas estrategias utilizadas para mitigar otros tipos de ataques XSS.

Si necesita invalidar los JWT, definitivamente hay formas de lograrlo. Almacenar una época por usuario sólo para los usuarios que han solicitado que se finalicen sus "otras sesiones" es un método muy eficiente que probablemente será lo suficientemente bueno. Si una aplicación necesita una invalidación por sesión, entonces se puede mantener un ID de sesión de la misma manera y la tabla de "tokens eliminados" aún se puede mantener mucho más pequeña que la tabla de usuarios completa (solo necesita conservar los registros más recientes que el duración máxima permitida del token). Por lo tanto, la capacidad de invalidar el token niega parcialmente el beneficio de las sesiones del lado del cliente en el sentido de que tendría que mantener esta sesión en estado cerrado. Lo más probable es que sea una tabla mucho más pequeña que la tabla de estado de sesión original, por lo que las búsquedas siguen siendo más eficientes.

Otro beneficio de usar tokens JWT es que es razonablemente fácil de implementar usando bibliotecas disponibles probablemente en todos los idiomas que pueda esperar tener. También está completamente divorciado de su esquema de autenticación de usuario inicial: si pasa a un sistema basado en huellas digitales, no necesita realizar ningún cambio en el esquema de administración de sesiones.

Un beneficio más sutil: debido a que el JWT puede transportar "información" y el cliente puede acceder a ella, ahora puede comenzar a hacer algunas cosas inteligentes. Por ejemplo, recuerde al usuario que su sesión caducará unos días antes de que cierre la sesión, dándole la opción de volver a autenticarse, según la fecha de caducidad del token. Todo lo que puedas imaginar.

En resumen: los JWT responden algunas de las preguntas y deficiencias de otras técnicas de sesión.

  1. Autenticación "más barata" porque puede eliminar un viaje de ida y vuelta a la base de datos (¡o al menos tener una tabla mucho más pequeña para consultar!), lo que a su vez permite la escalabilidad horizontal.

  2. Reclamaciones del lado del cliente a prueba de manipulaciones.

Si bien los JWT no responden a otras cuestiones como el almacenamiento o el transporte seguros, no introducen ningún problema de seguridad nuevo.

Existe mucha negatividad en torno a los JWT, pero si implementa la misma seguridad que implementaría para otros tipos de autenticación, todo estará bien.

Una nota final: tampoco se trata de cookies versus tokens. Las cookies son un mecanismo para almacenar y transportar bits de información y también pueden usarse para almacenar y transportar tokens JWT.

The Tahaan avatar Jul 20 '2017 12:07 The Tahaan

La respuesta corta es: Ninguna.

Una versión más larga es:

Implementé JWT para la gestión de sesiones después de leer esta recomendación en los documentos de GraphQL :

Si no está familiarizado con ninguno de estos mecanismos de autenticación, le recomendamos utilizar express-jwt porque es simple sin sacrificar ninguna flexibilidad futura.

La implementación fue realmente simple, ya que sólo añadió un poco de complejidad. Sin embargo, después de un tiempo, yo (al igual que usted) comencé a preguntarme cuáles eran los beneficios. Resulta que hay muy pocos (o posiblemente ninguno) para JWT en lo que respecta a la gestión de sesiones, como se explica en detalle en esta publicación de blog:

Deja de usar JWT para sesiones

Carl von Blixen avatar Jul 20 '2017 13:07 Carl von Blixen

Tuve una pregunta similar al elegir entre JWT y token + caché para la autenticación del usuario.

Después de leer estos artículos, me queda claro que los beneficios que promete JWT no superan los problemas que trae. Entonces token + caché (Redis/Memcached) es el camino a seguir para mí.

Encabezados de autenticación, JWT y sesiones: cómo elegir la técnica de autenticación adecuada para las API

Técnicas de autenticación para API

Deja de usar jwt para sesiones

h--n avatar Dec 30 '2019 15:12 h--n

Mi granito de arena, que de paso añade algo de contraste con la famosa publicación del blog de joepie91.

Teniendo en cuenta que las aplicaciones de hoy (y del mañana) son (en su mayoría) nativas de la nube, la autenticación Stateless JWT
tiene un beneficio económico , que escala a medida que la aplicación escala: las aplicaciones en la nube generan costos con cada segundo que pasa . Este costo se reduce cuando los usuarios ya no tienen que autenticarse "contra" un almacén de sesiones. A continuación se detallan algunos factores que aumentan el costo de una aplicación cuando no se utiliza JWT:

Servidor de base de datos
Ejecutar un almacén de sesiones las 24 horas del día, los 7 días de la semana cuesta dinero.
No puede salirse con la suya con soluciones basadas en almacenamiento/memoria local en el mundo de K8S, ya que los pods son efímeros.
A las sesiones fijas no les irá bien exactamente por la misma razón.

Almacenamiento
Almacenar datos cuesta dinero. almacenar datos en un SSD cuesta aún más.
Las operaciones relacionadas con la sesión deben resolverse rápidamente, por lo que una unidad óptica no es una opción.

E/S
Algunos proveedores de nube cobran dinero por la E/S relacionada con el disco.

Descargue
Circa 2022, es seguro asumir que la API y el almacén de sesiones son instancias de servidor separadas.
Algunos proveedores de nube cobran por descargar información de una instancia a otra.

Escalar el almacén de sesiones
Esto afecta a todos los factores antes mencionados.

Eyal Perry avatar Sep 21 '2019 09:09 Eyal Perry