¿Te gustaría aprender .NET?
Tenemos los cursos que necesitas.¡Haz clic aquí!
En este artículo vamos a analizar las ventajas y desventajas de usar un sistema de autenticación basado en JWT (JSON Web Tokens) frente al esquema tradicional basado en el uso de cookies y sesiones.
A fin de facilitar la comprensión, voy a presentarte una serie de resúmenes, que he ido adaptando a partir de recursos interesantes que encontré por la Internet. Si deseas consultar las fuentes originales, puedes encontrar los enlaces al final del artículo.
Sin más, empecemos.
Introducción
Si tienes en claro la diferencia entre cookies y sesiones, y cómo operan en conjunto, entonces podemos continuar hacia la primera pregunta.
¿Cookies o Tokens? ¿Qué es mejor?
Pregunta
He estado usando cookies y sesiones para gestionar la autenticación de usuarios en mis aplicaciones web, y estoy contento por lo simple que resulta su uso.
Sin embargo, un desarrollador iOS me comentó que lo nuevo y más adecuado es usar JWT (JSON Web Tokens).
Me dijo que JWT es el camino a seguir para implementar una autenticación en las aplicaciones móviles nativas. Sin dar ejemplos, simplemente comentó que las aplicaciones Android y iOS tienen problemas con las cookies.
He buscado información, pero no he encontrado algo que demuestre que los JSON Web Tokens sean superiores a las Cookies. Es más, me resultan tan similares que no he podido encontrar una diferencia importante, ni por qué se recomienda su uso con las aplicaciones móviles nativas.
Por lo menos a mi parecer, sí es posible usar Cookies en el desarrollo iOS.
Entonces mi pregunta es, para una aplicación móvil, ¿qué ventajas presenta una API que hace uso de JWT en vez de Cookies para la autenticación de usuarios?
Respuesta
Nosotros, como desarrolladores de software, tenemos una tendencia por aplicar todo aquello nuevo que encontramos. Por dar un ejemplo: si de pronto nos encontramos con un martillo que no hemos visto antes (a pesar de ser sólo una variante de las muchas que conocemos), comenzamos a ver todo como un «clavo». Sentimos la necesidad de aplicar todo aquello nuevo que vamos aprendiendo (en la gran mayoría de ocasiones).
Ahora bien, retomando la pregunta original:
- Es importante mencionar que, ni los JWT ni las Cookies constituyen en sí mismos un mecanismo de autenticación.
- El primero sólo define un formato de token, y el segundo es un mecanismo de gestión de estado para las peticiones HTTP.
- Sólo con esto determinamos que es incorrecto decir que uno es superior a otro.
Es correcto sin embargo que ambos son ampliamente utilizados en sistemas de autenticación.
Tradicionalmente las aplicaciones web han usado cookies (en conjunto con sesiones) para hacer un seguimiento de los usuarios que han iniciado sesión. De esta forma, no necesitan enviar sus credenciales en cada petición.
Generalmente, el contenido de una cookie está determinado por un identificador único (generado aleatoriamente). Este ID le permite al servidor encontrar los datos de sesión correspondientes para cada usuario.
Sin embargo, en el desarrollo de APIs es más común aceptar tokens (en formato JWT principalmente) para que el servidor decida si otorgar acceso o no a quien está realizado la petición.
Esto se debe a que:
- Tradicionalmente, el principal tipo de cliente (para visitar aplicaciones web) ha sido el
web browser(navegador web), que presenta un soporte completo para cookies. - Pero las APIs hoy en día son usadas también por clientes HTTP mucho más simples, que no soportan cookies de forma nativa.
La autenticación basada en cookies es conveniente para los navegadores, pero más allá de ellos, para otros tipos de clientes tiene más sentido un enfoque basado en tokens (ya que estos pueden ser transportados a través de parámetros, encabezados o como parte del cuerpo de las peticiones HTTP).
Es decir, si una API admite tokens entonces aumentará el rango de clientes que puede atender, por lo que resulta más conveniente si la API se debe usar más allá de los navegadores web.
Hoy en día es posible el uso de cookies en las aplicaciones móviles nativas, pero en resumen: los JWT tienen una ventaja sobre las cookies sólo por el hecho de que su uso es más común. Siguiendo este enfoque, podemos tener más recursos de aprendizaje, SDKs, información sobre las vulnerabilidades más conocidas, etcétera.
Autenticación basada en tokens VS autenticación basada en cookies y sesiones
A continuación vamos a repasar cómo funcionan las cookies (en conjunto con sesiones) y los tokens, para que luego nos resulte más fácil resaltar las diferencias.
Autenticación basada en cookies
La autenticación basada en cookies ha sido el método predeterminado (y comprobado) para manejar la autenticación de usuarios durante mucho tiempo.
La autenticación basada en cookies presenta un estado (es stateful).
Al iniciar sesión, luego que un usuario envía sus credenciales (y estas se validan), el servidor registra datos (con el fin de recordar que el usuario se ha identificado correctamente). Estos datos que se registran en el backend, en correspondencia con el identificador de sesión, es lo que se conoce como estado.
En el lado del cliente una cookie es creada para almacenar el identificador de sesión, mientras que los datos se almacenan en el servidor (y son llamados variables de sesión).
El flujo que sigue este sistema de autenticación tradicional es el siguiente:
- Un usuario ingresa sus credenciales (datos que le permiten iniciar sesión)
- El servidor verifica que las credenciales sean correctas, y crea una sesión (esto puede corresponderse con la creación de un archivo, un registro nuevo en una base de datos, o alguna otra solución server-side)
- Una cookie con el
session IDes puesta en el navegador web del usuario - En las peticiones siguientes, el
session IDes comparado con las sesiones creadas por el servidor - Una vez que el usuario se desconecta, la sesión es destruida en ambos lados (tanto en el cliente como en el servidor)
Autenticación basada en tokens
La autenticación basada en tokens ha ganado prevalencia en los últimos años debido al aumento de las Single Page Applications, web APIs y la Internet de las cosas (Internet of Things en inglés).
Cuando hablamos de autenticación con tokens, generalmente hablamos de autenticación con JSON Web Tokens (JWT).
Si bien existen diferentes implementaciones, los JWT se han convertido en el estándar de facto. Con ello en mente, en el resto del artículo, tokens y JWT se usarán indistintamente.
La autenticación basada en tokens carece de estado (es stateless).
El servidor ya no guarda información de qué usuarios están conectados o qué tokens se han emitido. Esto es así porque cada solicitud realizada al servidor va acompañada de un token, y el servidor verifica la autenticidad de la solicitud basándose únicamente en el token.
Como ya comentamos antes, JWT define un formato para los tokens. Pero JWT no nos ata a ningún mecanismo de persistencia de datos en el lado del cliente y tampoco a ninguna regla de cómo se debe transportar el token.
Los tokens se envían generalmente como un Authorization header, con el valor Bearer {JWT}; pero pueden enviarse también en el cuerpo de una petición POST o incluso como un query parameter.
Veamos cómo funciona:
- Un usuario ingresa sus credenciales (datos que le permiten iniciar sesión)
- El servidor verifica que las credenciales sean correctas, y devuelve un token firmado
- El token es guardado en el lado del cliente, comúnmente en el
local storage(pero puede guardarse también en elsession storageo incluso como una cookie) - Las peticiones siguientes al servidor incluyen este token (a través de un
Authorization headero alguno de los otros métodos antes mencionados) - El servidor decodifica el JWT y si el token es válido procesa la solicitud
- Una vez que el usuario se desconecta, el token es destruido en el lado del cliente (no es necesaria la interacción con el servidor)
Ventajas de la autenticación basada en tokens
Luego de comprender cómo funcionan ambos enfoques, vamos a ver las ventajas que presenta la autenticación basada en tokens sobre el enfoque tradicional basado en cookies.
Sin estado, escalable y desacoplado
Probablemente la mayor ventaja de usar tokens y no cookies es el hecho de que ofrecen una autenticación sin estado (stateless).
Desde backend no se necesita tener un registro de los tokens. Cada token es autónomo: contienen en sí mismos toda la data necesaria para confirmar su validez (así como también información puntual del usuario que ha iniciado sesión).
De esta forma, el único trabajo del servidor es: firmar tokens ante un inicio de sesión exitoso, y verificar que los tokens entrantes sean válidos.
Cross Domain y CORS
Las cookies funcionan bien con un dominio (o subdominio) en específico, pero cuando se trata de administrar cookies en diferentes dominios, el manejo se torna complicado.
En contraste, un enfoque basado en tokens con CORS habilitado hace que sea trivial exponer las APIs a diferentes servicios y dominios.
Dado que se requiere y se verifica un token en cada una de las llamadas al backend, siempre que haya un token válido, las solicitudes se pueden procesar.
Te esperamos en la segunda parte del artículo en donde hablaremos mas acerca de estos temas, los cuales hoy en día son de vital importancia en el mundo de la tecnología.
¿Te gustaría aprender .NET?
Tenemos los cursos que necesitas.¡Haz clic aquí!
