Express.js
Explica sesiones almacenadas en servidor, cookies de identificador, stores compartidos, rotación, expiración, revocación y despliegues con múltiples instancias.
Una session mantiene estado autenticado en el servidor y entrega al cliente un identificador opaco. Su principal ventaja es la revocación centralizada; su coste es operar un store compartido.
El navegador conserva una cookie con un ID aleatorio:
cookie session-id
↓
session store
↓
userId, expiración y metadataLa identidad real no necesita viajar en cada request. El servidor puede invalidar la session en cualquier momento.
Después del login, el servidor necesita reconocer requests posteriores. Guardar toda la identidad en una cookie expone y replica estado. Una session permite almacenar solo un identificador difícil de adivinar.
app.use(session({
name: '__Host-session',
secret: sessionSecrets,
resave: false,
saveUninitialized: false,
cookie: {
httpOnly: true,
secure: true,
sameSite: 'lax',
path: '/',
maxAge: 1000 * 60 * 60,
},
store,
}));La cookie contiene el ID firmado, no todo el objeto session.
El store por defecto no sirve para producción:
Utiliza un store mantenido, como Redis o una base adecuada, con expiración y observabilidad.
Un atacante puede intentar hacer que la víctima use un ID conocido. Después de autenticar, regenera:
request.session.regenerate((error) => {
if (error) return next(error);
request.session.userId = user.id;
request.session.save((saveError) => {
if (saveError) return next(saveError);
response.sendStatus(204);
});
});La regeneración cambia el ID y evita conservar una session pre-login.
Guarda lo mínimo:
No guardes perfiles enormes, entidades ORM ni permisos que deban reflejar cambios inmediatos sin estrategia de invalidación.
Expira tras inactividad. Puede renovarse con rolling sessions.
Limita la vida total incluso con actividad.
Combinar ambos reduce sessions eternas. Una session sensible puede requerir reautenticación reciente para acciones críticas.
Puedes revocar:
Mantén índices o versionado que permitan hacerlo eficientemente.
request.session.destroy((error) => {
if (error) return next(error);
response.clearCookie('__Host-session', cookieOptions);
response.sendStatus(204);
});Borrar la cookie sin destruir el store deja una session activa si el ID se recupera.
Con store compartido, múltiples instancias pueden resolver la misma session sin sticky sessions. El store se convierte en dependencia crítica:
Cachear session localmente puede mejorar latencia pero complica revocación.
Dos requests pueden modificar la misma session simultáneamente y sobrescribirse. Evita utilizar la session como base de estado de negocio mutable. Almacena identidad y contexto pequeño; el dominio vive en su base.
const authenticateFromSession: RequestHandler = async (request, response, next) => {
const userId = request.session.userId;
if (!userId) {
response.status(401).json({ code: 'AUTHENTICATION_REQUIRED' });
return;
}
const actor = await users.findActiveActor(userId);
if (!actor) {
request.session.destroy(() => undefined);
response.status(401).json({ code: 'INVALID_SESSION' });
return;
}
response.locals.actor = actor;
next();
};La session identifica. El servidor vuelve a resolver estado actual cuando permisos o activación importan.
La API quizá no pueda autenticar. Responde indisponibilidad sin tratar al usuario como anónimo si eso cambia seguridad.
Un store externo conserva sessions. El MemoryStore las perdería.
Invalida sessions existentes o usa una sessionVersion comparada con usuario.
Revocación, expiración corta, device metadata y reautenticación reducen impacto.
Evita contadores o carrito crítico dentro del objeto session sin control de concurrencia.
Sessions facilitan revocación y navegadores, pero añaden un lookup y store. Tokens autocontenidos reducen lookup, pero complican revocación y estado obsoleto. La elección depende de clientes, escala y threat model.
Tokens y JWT con criterio compara estado server-side con credenciales firmadas y sus límites de revocación.