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.Su definición de cookie realmente no describe lo que hacen. Una cookie es un par clave-valor que
Set-Cookieel servidor establece a través del encabezado de respuesta HTTP ( ) y lo almacenan los clientes que los admiten. Las cookies se devuelven con cada solicitud posterior (en elCookieencabezado) para el esquema de coincidencia de solicitudes, host, ruta, https mientras la cookie no ha expirado. Puede almacenar cualquier cosa que desee en una cookie, y le permite admitir el estado en el protocolo sin estado de HTTP.Un ejemplo de intercambio de cookies se ve así:
Eso es bastante correcto. Una sesión son datos que se almacenan en el lado del servidor sobre la sesión actual de un usuario. Para que esto funcione en un protocolo sin estado como HTTP, el usuario debe enviar su ID de sesión con cada solicitud, para que el servidor pueda obtener la sesión correcta para el usuario. La identificación de la sesión generalmente se almacena en una cookie (ver arriba). Esta no es una cookie diferente a cualquier otra cookie, los datos son solo la ID del servidor para la sesión del usuario.
Eso es bastante cierto. Todo se almacena en el token. El token puede almacenarse en una cookie (ver arriba). Esta es una alternativa a las sesiones del servidor, y funciona porque el token está firmado y verificado por el servidor, por lo que no se puede alterar ni falsificar, y es seguro almacenarlo en el lado del cliente.
fuente