session - metodo - jwt java ejemplo
Autenticación: uso de JWT vs sesión (2)
JWT no tiene un beneficio sobre el uso de "sesiones" por decir. 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 al preguntar esto es "¿Cuáles son los beneficios de usar JWTs sobre el uso de sesiones del lado del servidor "
Con las sesiones del lado del servidor, tendrá que almacenar el identificador de sesión en una base de datos o guardarlo en la memoria y asegurarse de que el cliente siempre llegue 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 una cosa que mantener, esencialmente una consulta adicional que se debe hacer con cada solicitud.
Con una solución en memoria, limita su escala 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 elimina la dependencia de una sesión del lado del servidor, pero impone su propio conjunto de desafíos.
- Almacenar el token de forma segura
- transportarlo de forma segura
- Las sesiones de JWT a veces pueden ser difíciles de invalidar.
- Confiando en el reclamo del cliente.
Estos problemas son compartidos por JWT y otros mecanismos de sesión del lado del cliente por igual.
JWT en particular aborda el último de estos. Puede ser ú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 podría ser cualquier cosa, incluso la ID de sesión o el perfil completo del usuario.
(Sin embargo, no haga eso) Tiene una firma segura que evita que las partes maliciosas generen tokens falsos (necesita acceso a la clave privada del servidor para firmarlos y puede verificar que no se modificaron después de que se firmaron) envíelos con cada solicitud, tal como se enviaría una cookie o encabezado de
Authorization
.
De hecho, se envían comúnmente en el encabezado de
Authorization
HTTP, pero también está bien usar una cookie.
El token está firmado y el servidor puede verificar su origen. Asumiremos que el servidor confía en su propia capacidad para firmar de forma segura (debe usar una biblioteca estándar: no intente hacerlo usted mismo y asegure el servidor correctamente)
Sobre el problema de transportar de forma segura el token, la respuesta suele ser enviarlo a través de un canal encriptado, generalmente httpS.
Con respecto al almacenamiento seguro del token en el cliente, debe asegurarse de que los malos no puedan acceder a él. Esto (principalmente) significa evitar que JS de sitios web defectuosos lean el token para enviarlo de vuelta a ellos. Esto se mitiga utilizando las mismas estrategias utilizadas para mitigar otros tipos de ataques XSS.
Si necesita invalidar JWT, definitivamente hay formas de lograrlo. El almacenamiento de una época por usuario solo 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 una ID de sesión de la misma manera y la tabla de "tokens eliminados" aún se puede mantener para ser mucho más pequeña que la tabla de usuario completa (solo necesita conservar registros más nuevos que el la duración de token más larga permitida.) Por lo tanto, la capacidad de invalidar el token niega parcialmente el beneficio de las sesiones del lado del cliente, ya que tendría que mantener este estado de sesión desactivada. Es muy probable que sea una tabla mucho más pequeña que la tabla de estado de sesión original, por lo que las búsquedas son aún más eficientes.
Otro beneficio de usar tokens JWT es que es razonablemente fácil de implementar usando bibliotecas disponibles en probablemente todos los idiomas que puede esperar tener. También está completamente divorciado de su esquema de autenticación de usuario inicial: si cambia a un sistema basado en huellas dactilares, no necesita realizar ningún cambio en el esquema de administración de la sesión.
Un beneficio más sutil: dado que el JWT puede transportar "información" y el cliente puede acceder a esto, ahora puede comenzar a hacer algunas cosas inteligentes. Por ejemplo, recuérdele al usuario que su sesión expirará unos días antes de cerrar sesión, brindándole la opción de volver a autenticarse, en función de la fecha de vencimiento del token. 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 redondo de base de datos (¡o al menos tener una tabla mucho más pequeña para consultar!), 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 otros problemas, como el almacenamiento o el transporte seguro, no presenta ningún problema de seguridad nuevo.
Existe mucha negatividad en torno a los JWT, pero si implementa la misma seguridad que para otros tipos de autenticación, estará bien.
Una nota final: tampoco es Cookies vs Tokens. Las cookies son un mecanismo para almacenar y transportar bits de información y también se pueden utilizar para almacenar y transportar tokens JWT.
¿Cuál es la ventaja de JWT sobre el uso de la sesión en situaciones como la autenticación?
¿Se usa como enfoque independiente o se usa en la sesión?
La respuesta corta es: ninguna.
Una versión más larga es:
Implementé JWT para la administración de sesiones después de leer esta recomendación en los documentos 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 solo agregó un poco de complejidad. Sin embargo, después de un tiempo, (como 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 administración de sesiones, como explica esta publicación de blog en detalle: