Sesiones vs JWT: qué cambia y cuándo usarlos
Curso de OAuth 2.0 y OpenID Connect: Flujos de Autenticación y Casos de Estudio
Contenido del curso
Curso de OAuth 2.0 y OpenID Connect: Flujos de Autenticación y Casos de Estudio
Clase 8 de 25
Clase 8 / 25
Zaidibeth Ramos
Facundo Castro
Jorge Adoney Espinosa Gómez
Guillermo Rodas
Profesor
Juan Pico
Steve Anthony Luzquiños Agama
Angel Javier Sanchez Tenjo
ROSA PINAS
Fernando Moyano
Luisa Fernanda Duque Ortiz
Francisco Israel Teneda Gallardo
Trataria en la medida de lo posible evitar las sesiones para optimizar los costos en memoria. Sin embargo, pueden ser utiles en casos como los de aplicaciones bancarias que necesitan mayor nivel de seguridad y no se deberian realizar requests de un mismo usuario desde distintas sesiones al mismo tiempo. Respecto a los tokens, los usaria en aplicaciones de uso comun, donde se realizan transacciones simples.
Un token puede resolver problemas cuando, por ejemplo, se una misma aplicación tanto para el navegador de la computadora o en una aplicación de teléfono móvil. Cuando se olvida de cerrar una sesión en una computadora (ajena), la aplicación del teléfono puede cerrarla de forma remota. Como sucede con WhatsApp.
Con respecto a enviar los datos de ID se session o el JWT por cookies estuve leyendo sobre un tipo de exploit llamado CSRF que básicamente se aprovecha de los datos de session almacenados en cookies para "secuestrar" la session del usuario víctima y realizar una petición que requiere autorización haciéndose pasar por el usuario. ¿Entonces no sería mejor no enviar ni almacenar estos datos de session y autorización por medio de cookies?
Los ataques CSRF se suelen combatir mediante el envío de un estado (state) que solo conoce tu sesión actual y el backend.
¿tienes el link del articulo a la mano para revisar de que se trata y darte una respuesta más acertada?
Tengo una pregunta. ¿Cómo podría guardar información sensible de manera segura en un JWT? Cuando uso sesiones a veces se guarda en sesión info sensible que está asociada al usuario y al estar en el server pues digamos que está un poco más protegida, pero según dices no es recomendable guardar info sensible en el payload de un JWT ¿Tendría que consultarla en cada petición que se haga? ¿No sería una carga adicional de tráfico a la bd?
No debes guardar info sensible de un usuario en un JWT. Lo que he hecho es guardar el id en el token, y consultar info de sesión en una capa de caché, usando un Redis por ejemplo. Claro que esta solución necesita una bd para el sistema y una capa de caché interna o externa.
🔐 Usaría sesiones cuando:
📌 Conclusión:
Usaría sesiones cuando el servidor es el “dueño del estado” y la arquitectura no exige statelessness.
🔑 Usaría tokens (JWT) cuando:
📌 Conclusión:
Usaría JWT cuando necesito desacoplamiento, escalabilidad y comunicación entre múltiples servicios sin mantener estado en el servidor.
uno de los peores tutores...
porqué ? justificá tu respuesta.
Una pregunta si voy a validar unos servicios que consume mi propia aplicación que está hecha en aspx y tiene manejo de sesiones para la validación de usuarios pero además tengo unas página html que tienen embebido cada una un componente de REACT y este hace llamados a unos servicios web api en .net, que tipo de autenticación me recomendarías hacer? Aclaró que todo es la misma aplicación y mis propios servicios pero como se acceden desde REACT tiene q quedar completamente público con la url del dominio, no puedo usar localhost porque no lo encontraría desde el lado del cliente. Agradezco de antemano tu respuesta
Comparto un articulo interesante: ~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
