Cookies, Local Storage e IndexedDB: qué es realmente una sesión

Iniciar sesión escribe en tres lugares distintos. Saber cuál es cuál explica por qué las sesiones sobreviven a unas cosas, se rompen con otras, y por qué sincronizar un perfil exige mover los tres.
"Tener la sesión iniciada" parece una sola cosa. Son al menos tres, guardadas en tres lugares distintos con tres duraciones distintas, y esa diferencia explica la mayor parte del comportamiento desconcertante con el que se topa la gente al mover sesiones entre equipos.
Cookies
Pequeños pares clave-valor, enviados automáticamente con cada petición al sitio que los estableció. Es donde suele vivir el token de sesión.
- Con ámbito de dominio y ruta, y con fecha de caducidad.
- Una cookie `Secure` solo se envía por HTTPS; una cookie `HttpOnly` es invisible para el JavaScript de la página.
- Una cookie de sesión no tiene caducidad y está pensada para desaparecer cuando se cierra el navegador.
Las cookies son las más pequeñas de las tres y las que más carga soportan. Si las pierdes, se cierra tu sesión.
Local Storage y Session Storage
Almacenamiento clave-valor de cadenas, que lee y escribe el JavaScript de la página, con ámbito por origen. Nunca se envía con una petición. La página tiene que leerlo deliberadamente.
Las aplicaciones guardan aquí preferencias, datos de perfil en caché, indicadores de funciones y, a menudo, un token de renovación. Local Storage persiste hasta que se borra; Session Storage dura solo lo que dura la pestaña.
IndexedDB
Una base de datos de verdad dentro del navegador: registros estructurados, índices, transacciones. Es donde una aplicación web moderna guarda todo lo sustancial: historiales de mensajes en caché, colas sin conexión, claves de cifrado para funciones con cifrado de extremo a extremo.
Por qué importa para un perfil
Da al "aislamiento" un significado preciso. Dos perfiles están aislados cuando los tres almacenes están separados, además de la caché y el estado de las extensiones. Una herramienta que aísla las cookies pero comparte IndexedDB ha aislado la parte fácil, el tercio más sencillo del problema.
También marca el listón para mover un perfil entre equipos. Llevar solo las cookies reproduce la forma de una sesión sin su sustancia.
| Almacén | Lo escribe | Suele contener |
|---|---|---|
| Cookies | El servidor y el script de la página | Token de sesión, preferencias, identificadores de seguimiento |
| Local Storage | El script de la página | Tokens de renovación, estado de la interfaz, datos de perfil en caché |
| Session Storage | El script de la página | Estado por pestaña, que se descarta al cerrar la pestaña |
| IndexedDB | El script de la página | Datos en caché, colas sin conexión, claves de cifrado |
Mover una sesión entre tus propios equipos
PowerOps captura las cookies, Local Storage e IndexedDB cuando se cierra un perfil y las restaura cuando se abre en otro lugar. Cada categoría es un interruptor, para todo el espacio de trabajo o para un solo perfil, de modo que puedes mover exactamente lo que pretendes mover.
Conviene conocer dos propiedades de cómo funciona:
- La instantánea se cifra en el equipo de origen, con una clave que pertenece al espacio de trabajo, y se descifra en el equipo que abre el perfil. No es cifrado de extremo a extremo: el servicio conserva una copia de esa clave para que tus otros ordenadores puedan recibirla.
- Un perfil está abierto en un solo equipo a la vez. Mientras está abierto mantiene una concesión (lease), y a otro dispositivo se le indica qué dispositivo la tiene en lugar de permitirle bifurcar la sesión en dos copias divergentes.
Ese segundo punto es una limitación deliberada. Dos equipos que editan una misma sesión de forma independiente producen dos sesiones a medio validar y, con bastante frecuencia, una cuenta con la sesión cerrada en ambos. Un almacén de cookies no tiene forma de resolver un conflicto de fusión.
La conclusión práctica
Cierra los perfiles en lugar de matarlos. La escritura al cerrar es lo que hace portátil la sesión, y es el hábito más barato de esta lista.

