Autenticación tradicional vs JWT

Clase 6 de 39 • Curso de Autenticación con Passport.js 2019

Resumen

Cuando usamos una autenticación tradicional se crea una sesión y el ID de esa sesión se almacena en una cookie del navegador, pero cuando utilizamos JWT firmamos un token y este se guarda en el navegador el cual permite a una SPA actualizarse sin refrescar la ventana.

David Behar

student•

Auth tradicional

Se crea una sesión (el id se almacena en una cookie)
Los request de ahí en adelante (hasta que expire) vienen con la información de la cookie

Problemas del auth tradicional Las SPA no refrescan todas las veces (y no saben si hubieron cambios en la sesión) Las REST API no deberían tener estado, al crear sesiones se crea estado Para microservicios las sesiones de una sóla máquina no fluyen naturalmente hacia varios clientes El control de acceso requiere que vayamos a base de datos

JSON Web Tokens Auth

En el proceso de Autenticación el server firma un token
A partir de ese momento el cliente almacena el token en memoria y en una cookie
Todos los request de ahí en adelante llevan el token

Ventajas de JWT

No requiere del backend para saber si está autenticado porque lleva una firma (post autenticación)
El backend puede recibir multiples request de multiples clientes (sólo necesita saber si el token está bien firmado)
El cliente conoce los permisos que tiene, por lo que no los tiene que bajar de base de datos

Javier Armando Vargas Vega

student•

Gracias

Tatiana Karina Valencia Hernández

student•

Gracias, buen aporte

Eduardo Serrano Jaime

student•

Uno de los problema que he observado usando jwt es cuando cambias los permisos del usuario y no es hasta que el usuario se desloguea y vuelve a ingresar que el cambio de los permisos se hacen visibles para el usuario

Maria Elizabeth Minero Alvarenga

student•

Ventajas de JWT

No requiere del backend para saber si está autenticado porque lleva una firma (post autenticación)
El backend puede recibir multiples request de multiples clientes (sólo necesita saber si el token está bien firmado)
El cliente conoce los permisos que tiene, por lo que no los tiene que bajar de base de datos

Angie Mayoli Cortes Montaño

student•

Interesante lo de las cookies que son llamadas asi por las galletas de la fortuna que contienen mensajes :) !!!

David Behar

student•

Si llegamos a saber cuál es el algoritmo de encriptación (usando alguno tradicional) ¿no acabaríamos comprometiendo toda nuestra app?

Erik Elyager

student•

Para romper los algoritmos de encriptación actuales necesitas a parte de conocer cómo funciona el algoritmo, una llave secreta que es muy difícil de conseguir. Por lo que ya no basta con sólo saber el algoritmo.

Fer Torres

student•

No necesariamente. Eso depende de cuál fue el método de encriptación y lo dificíl que sería "romperlo". Un ejemplo muy general: en México, el Servicio de Administración Tributaria utiliza seguridad asimétrica (llaves públicas y privadas) para crear tus archivos de certificado FIEL (Firma Fiel Avanzada); si conoces el RFC de un contribuyente, todo mundo puede obtener de la web del SAT la llave pública de dicho RFC con datos adicionales (nombre, CURP, rep legal, etc), pero aunque la conozcas y sepas qué usa el SAT para generar el par de llaves, es casi imposible (por ahora) lograr obtener la otra llave o la contraseña.

Jose Daniel Molina

student•

Esto me pone a pensar que la autenticación con JWT hace más eficaz la aplicación, ya que no necesita ir a base de datos para consultar los permisos y no depende del backend para saber si un usuario está o no autenticado. Pienso que por eso es que en ocasiones al abandonar sitios web y volver a entrar, nuestro login sigue activo, porque hay un token.

Félix Andersson

student•

A que se refiere con que las REST API no tienen estado y las sesiones si lo tienen?

Sebastian Elias Medina Donoso

student•

buena pregunta

Daniel Esteban Santos Mendez

student•

Las peticiones http no tiene estado y no deberían manejar estado, al estar enviando y trayendo al servidor siempre una cookie con los datos de la sesión del usuario le estamos dando un estado a las peticiones, porque la sesión del usuario es un estado, o sea trae información con la cual nos dice si podemos o no hacer cosas dentro de la app.

Juan David González Rodríguez

student•

JWT es genial !! :D jaja

Alejandro González Reyes

student•

En aplicaciones spa modernas el JWT se guarda en cookies o en localstorage. Digamos si mi API va a ser consumida por un spa o aplicación móvil

Ivan Dario Villa

student•

Lo más recomendable es guardarlo en memoria, ya que si alguien tiene acceso a este token lo puede usar mientras este no expire.

Gaspar Dolcemascolo

student•

Que son los micro servicios y los servicios web. Me pueden dar ejemplos?

Daniel Adolfo Ordoñez Rubio

student•

Hola :) Servicios web técnicamente se refiere al uso de protocolos para la comunicación e intercambio de datos entre aplicaciones. En la práctica, puede ser algo tan simple como pedir datos a una URL, por ejemplo https://cataas.com/cat retorna una foto aleatoria de un gatito

Esto es "consumir una API", hay un servidor que aloja una aplicación web simple que se realiza una tarea (devolver fotos de gatos), y usamos protocolos (web) para comunicarnos con ese servidor consumir sus servicios por medio de una API (en este caso una API REST).

:D Te dejo esto por aquí Curso de API REST :eyes:

La idea de micro servicios es que en lugar de tener una APP que hace todo (monolitica), tengas varias mini apps que solo hace una cosa, y así solo llamas (consumes) las que necesitas.

Gaspar Dolcemascolo

student•

Ok, servios web son por ejemplo las API. Que ejemplo de micro servios conoces que me puedan ayudar a tener una mejor idea? Gracias por responder =D