Cookies: en su versión inicial, un archivo de texto con un ID de cliente único y toda la otra información necesaria sobre el cliente (por ejemplo, roles)
Las cookies son tuplas key-valueoriginalmente dirigidas para retener datos relacionados con la actividad del cliente. Esta retención es lo que conocemos como estado de sesión o aplicación . Fundamentalmente, se hicieron para mantener el estado de las aplicaciones web; más específicamente, el estado en el lado del cliente. (1)
Las cookies generalmente las establece el servidor a través de encabezados de respuesta ( Set-Cookie key=value). Sin embargo, también pueden ser configurados por el cliente. Por ejemplo, por DOM ( document.cookie).
Una cosa importante que debe saber sobre las cookies es que no identifican a los usuarios. Más bien asocian los datos terna - cliente - servidor / ruta . (3)
Por lo general, asociamos cookies con archivos porque durante los primeros días de los navegadores web tenían que conservar las cookies de alguna manera, siendo los archivos el soporte más factible. Los navegadores actuales almacenan cookies (entre otras cosas) en almacenes locales (bases de datos integradas).
Sesión: solo la identificación única del cliente se envía en un archivo (también llamado cookie), todo lo demás se almacena en el servidor.
Por sesión, supongo que te refieres a las sesiones del servidor . Como comenté, las sesiones también se pueden implementar en el lado del cliente. La diferencia con las sesiones del lado del cliente es que los datos se almacenan en algún lugar del lado del servidor. (2) En tales escenarios, lo que obtenemos es una identificación de sesión; y lo obtenemos en forma de cookie. Sin la identificación de la sesión, el servidor no podría correlacionar las solicitudes entrantes con la actividad previa del cliente. (3) Por ejemplo, el usuario autenticado, el carrito de compras, etc.
En cualquier caso, una ID de sesión no necesariamente identifica a un usuario. Asocia un estado de aplicación específico con un cliente web. Las sesiones pueden o no contener datos de usuario.
En aplicaciones distribuidas, la sesión debe ser serializable por razones obvias. Si se almacenan en la memoria, el almacenamiento en memoria (componente) debe ser serializable. Una solución común es almacenar sesiones en archivos. O en NoSQL DB como Redis.
En cuanto a seguridad. Las sesiones del lado del servidor son más seguras que las del lado del cliente. Los clientes son más vulnerables a las amenazas porque los usuarios generalmente desconocen las tantas amenazas a las que están expuestos. Al menos no el usuario habitual.
Por otro lado, atacar una infraestructura del lado del servidor no es trivial.
JWT: todo se almacena en el token (que también podría almacenarse en un archivo de texto, que también se llama cookie)
Realmente no. JWT almacena datos principalmente relacionados con la autorización y el emisor del token.
Aunque suelen contener el ID de usuario (sub), encontramos JWT que no identifican usuarios autenticados. Por ejemplo, tokens para sesiones de invitados. El contenido principal de los JWT son las reclamaciones ; elementos a verificar por el proceso de autorización.
Es importante tener en cuenta que los JWT no son almacenamientos globales . La sesión o el estado de la aplicación aún deben almacenarse en algún lugar y administrarse de forma independiente.
Con respecto a los JWT, estos a menudo se almacenan como cookies, aunque también se pueden almacenar en almacenes locales. Además, la comunidad OWASP considera que sessionStorage es el más seguro para los navegadores web. Sin embargo, depende de la versión del navegador .
1: La World Wide Web está destinada a ser apátrida. Si queremos construir aplicaciones del lado del servidor sin estado, las sesiones deben almacenarse en algún lugar del lado del cliente.
2: Convertir la aplicación del lado del servidor en una aplicación con estado .
3: Cliente como aplicación, no como usuario.
user_idpara un usuario conectado.