Implementar Gestión de Sesiones Segura

Visión General

Las sesiones mantienen a un usuario autenticado entre requests en un protocolo sin estado. Tras el login, el servidor emite un ID de sesión — un token aleatorio en una cookie HttpOnly — y cada request posterior se asocia a ese usuario a través de él. Si esto falla, un ID de sesión filtrado es una contraseña robada con fecha de caducidad.

La gestión segura de sesiones se resume en cuatro cosas: IDs impredecibles, transporte solo por HTTPS, un store server-side con expiración, e invalidación en logout y cambios de privilegio. Esta receta cubre las cuatro con código listo para Express, Spring Boot y FastAPI.

Cuándo Usarlo

• Aplicaciones web server-rendered con login: paneles de administración, carritos de compra, portales.
• Necesitás revocación instantánea — una cuenta comprometida debe perder sus sesiones ya, no cuando expire un JWT.
• Varios servidores de aplicación detrás de un load balancer necesitan un store de sesiones compartido.
• Estás eligiendo entre sesiones stateful y autenticación JWT stateless — y te inclinás por stateful porque la revocación y el límite de dispositivos importan.

Solución

Express.js con sesiones en Redis

// connect-redis v7+ — RedisStore es un named export, sin factory call
const session = require('express-session');
const { RedisStore } = require('connect-redis');
const { createClient } = require('redis');

const redisClient = createClient({ url: 'redis://localhost:6379' });
await redisClient.connect(); // obligatorio en node-redis v4

app.use(session({
  store: new RedisStore({ client: redisClient }),
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  name: 'sessionId',
  cookie: {
    httpOnly: true,
    secure: true,
    sameSite: 'strict',
    maxAge: 3600000, // 1 hora
  },
}));

Spring Boot con Redis

@Configuration
@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 3600)
public class SessionConfig {
    @Bean
    public LettuceConnectionFactory connectionFactory() {
        return new LettuceConnectionFactory();
    }
}

// Controller
@PostMapping("/logout")
public ResponseEntity<Void> logout(HttpSession session) {
    session.invalidate();
    return ResponseEntity.noContent().build();
}

Endpoint de login con filtro de autenticación

@RestController
@RequestMapping("/api/auth")
public class AuthController {

    @PostMapping("/login")
    public ResponseEntity<?> login(@RequestBody LoginRequest req,
                                    HttpServletRequest request) {
        User user = userService.authenticate(req.email(), req.password());
        if (user == null) {
            return ResponseEntity.status(401).body("Credenciales inválidas");
        }

        HttpSession session = request.getSession(true);
        session.setAttribute("userId", user.getId());
        session.setMaxInactiveInterval(30 * 60); // 30 minutos

        return ResponseEntity.ok(Map.of("status", "logged_in"));
    }
}

@Component
public class AuthFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest req,
                                    HttpServletResponse res,
                                    FilterChain chain) throws ServletException, IOException {
        HttpSession session = req.getSession(false);
        if (session == null || session.getAttribute("userId") == null) {
            res.setStatus(401);
            res.getWriter().write("No autorizado");
            return;
        }
        chain.doFilter(req, res);
    }
}

Protección CSRF (Django)

Django incluye la protección CSRF en el middleware — lo principal es no desactivarla:

# settings.py — mantené esto habilitado
MIDDLEWARE = [
    # ...
    'django.middleware.csrf.CsrfViewMiddleware',
    # ...
]

<!-- login.html — el token va dentro de cada formulario POST -->
<form method="post">
  {% csrf_token %}
  <input name="username">
  <input name="password" type="password">
  <button type="submit">Iniciar sesión</button>
</form>

Sin {% csrf_token %} el middleware rechaza el POST. Para la versión manual y setups con SPA, mirá protección CSRF.

Explicación

Todo framework que valga la pena genera los IDs de sesión con un CSPRNG — 128 bits como mínimo. Express, Django y Spring lo hacen; si te tienta construir un ID propio, no lo hagas.

Las flags de la cookie resuelven el transporte. HttpOnly saca el ID del alcance de JavaScript, así que un payload XSS no puede leerlo. Secure hace que la cookie nunca viaje por HTTP plano — si la omitís, cualquiera en el mismo WiFi de la cafetería se queda con la sesión. SameSite=Strict (o Lax) evita que el navegador la adjunte en requests cross-site, tu primera línea de defensa contra CSRF.

Y el store es lo que lo hace manejable: con los datos de sesión en Redis o una base de datos podés matar una sesión al instante y compartirla entre todos los servidores de aplicación que corras.

Protección contra session fixation

Si un atacante puede plantarle a la víctima un ID de sesión conocido antes del login, hereda la sesión autenticada después. La solución: regenerar el ID tras un login exitoso.

router.post("/login", async (req, res) => {
  const user = await User.authenticate(req.body.email, req.body.password);
  if (!user) return res.status(401).json({ error: "Credenciales inválidas" });

  req.session.regenerate((err) => {
    if (err) return res.status(500).json({ error: "Error de sesión" });
    req.session.userId = user.id;
    res.json({ status: "logged_in" });
  });
});

Control de sesiones concurrentes

Para limitar a un usuario a N dispositivos, mantené una lista de sus IDs de sesión activos en Redis. Cuando un nuevo login supera el tope, borrá del store los IDs recortados — esos son los que mueren.

import redis

r = redis.Redis()
MAX_SESSIONS = 3

def on_login(user_id, session_id):
    key = f"user_sessions:{user_id}"
    r.lpush(key, session_id)
    r.ltrim(key, 0, MAX_SESSIONS - 1)
    # Borrar del store los IDs recortados
    dropped = r.lrange(key, MAX_SESSIONS, -1)
    for old_id in dropped:
        r.delete(f"session:{old_id}")
    r.ltrim(key, 0, MAX_SESSIONS - 1)

def is_session_valid(session_id):
    return r.exists(f"session:{session_id}")

Recortar la lista no alcanza — los IDs expulsados siguen resolviendo en el store hasta que los borrás.

Variantes

Enfoque	Revocación	Mejor para
Memoria	Instantánea	Dev, prototipos
Redis	Instantánea	Apps de producción
Base de datos	Instantánea	Si no hay Redis
JWT	Requiere blocklist	SPAs, móvil

Alternativa stateless: FastAPI + JWT

Cuando el cliente no es un navegador — una app móvil u otro servicio — un token firmado le gana a la cookie de sesión. El costo es la revocación: no podés matar un JWT antes de tiempo sin maquinaria extra como la rotación de refresh tokens.

from datetime import datetime, timedelta, timezone
from jose import jwt, JWTError
from fastapi import Depends, HTTPException, status
from fastapi.security import OAuth2PasswordBearer

SECRET_KEY = "your-secret-key"  # Cargar desde env en producción
ALGORITHM = "HS256"
ACCESS_TOKEN_EXPIRE_MINUTES = 30

oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token")

def create_access_token(data: dict) -> str:
    to_encode = data.copy()
    expire = datetime.now(timezone.utc) + timedelta(minutes=ACCESS_TOKEN_EXPIRE_MINUTES)
    to_encode.update({"exp": expire})
    return jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)

def get_current_user(token: str = Depends(oauth2_scheme)):
    credentials_exception = HTTPException(
        status_code=status.HTTP_401_UNAUTHORIZED,
        headers={"WWW-Authenticate": "Bearer"},
    )
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])
        user_id: str = payload.get("sub")
        if user_id is None:
            raise credentials_exception
        return user_id
    except JWTError:
        raise credentials_exception

Lo Que Funciona

• Rotá los IDs de sesión tras el login — es la solución completa al session fixation.
• Timeout de inactividad corto con refresh deslizante — expirá a los 30 minutos de inactividad y extendé en cada request válido.
• Invalidá en logout — borrá la entrada del store; limpiar la cookie del cliente solo deja la sesión viva.
• Vinculá a fingerprint de dispositivo en apps de riesgo — marcá sesiones cuya IP o User-Agent cambie a mitad de camino.
• Logueá anomalías de autenticación — logins desde dos países en diez minutos, o ciclos rápidos de login/logout, son señales de takeover.
• SameSite=Lax como mínimo — bloquea la mayoría del CSRF sin romper la navegación normal.

Errores Comunes

• Datos sensibles en cookies del cliente — las cookies son legibles y robables; el estado va en el servidor.
• Flag Secure ausente en producción — HttpOnly no sirve de nada si la cookie viaja por HTTP plano.
• Sesiones que nunca expiran — cada ID robado queda válido para siempre. Limitá inactividad y vida absoluta.
• No regenerar al cambiar privilegios — un reset de contraseña o elevación de rol debería matar todas las sesiones existentes.
• JWTs en localStorage — cualquier XSS lo lee. Si no hay alternativa, acompañalo con un CSP estricto — o directamente usá cookie.
• Sin timeout de inactividad — una computadora compartida convierte una sesión abierta en una puerta trasera permanente.

Cuándo No Usarlo

• SPA o cliente móvil puro — las cookies y CORS estorban; los Bearer tokens (JWT) encajan mejor.
• API pública de solo lectura — sin estado de usuario no hay nada que persistir; aplicá rate limiting en vez de autenticación.
• Tráfico machine-to-machine — los servicios no hacen login; usá API keys o mTLS.
• Prototipo de un solo servidor — las sesiones en memoria alcanzan hasta que agregás la segunda instancia.
• Edge con latencia crítica — pagar un round trip a Redis por request se nota en el p99; la validación JWT es local.

Notas de Rendimiento

Olvidate de los micro-benchmarks — los costos reales son arquitectónicos:

• Una consulta de sesión a Redis cuesta un round trip por request (~1ms dentro del datacenter, más entre regiones). Verificar un JWT cuesta una firma — sin red.
• La memoria de sesión es pequeña pero real: ~500 bytes por entrada, así que 100K sesiones activas entran en ~50MB de Redis.
• bcrypt con costo 12 quema ~250ms de CPU por login. Con 100 logins/segundo son 25 núcleos de hashing — ajustá el factor de costo, no el algoritmo.
• La recompensa es la velocidad de revocación: borrar una sesión es instantáneo, mientras un JWT robado sigue válido hasta expirar o caer en una blocklist.

Estrategia de Testing

• Bypass de autenticación: los endpoints protegidos rechazan requests sin sesión válida.
• Fixation: el ID de sesión cambia después del login.
• Expiración: las sesiones inactivas mueren en el timeout configurado; la vida absoluta se mantiene bajo refresh deslizante.
• Límites concurrentes: la sesión N+1 invalida la más vieja.
• Logout: la entrada del store desaparece, no solo la cookie.
• CSRF: los POST que cambian estado sin token son rechazados.

Notas de Costos

No hay licencia que comprar — la gestión de sesiones es una instancia de Redis más tiempo de CPU. Las piezas móviles:

• Redis: una instancia gestionada pequeña cubre cientos de miles de sesiones; la memoria rara vez es el límite.
• Cómputo de login: dominado por el hashing de contraseñas — mirá la nota de bcrypt arriba.
• Monitorización: las métricas de autenticación (logins fallidos, sesiones activas, emisión de tokens) salen de tu stack actual; no hace falta un producto dedicado.

Checklist de Despliegue

• Flags de cookie configurados: HttpOnly, Secure, SameSite=Lax o Strict
• Timeout de inactividad (30 min) más un máximo absoluto (8–24h)
• Solo HTTPS; HTTP redirige a HTTPS
• Regeneración de sesión en login y en cambios de privilegio
• Rate limiting en endpoints de login y reset de contraseña — ver rate limiting
• Job de limpieza que purga entradas expiradas de Redis
• Flujo de autenticación completo probado end-to-end: login, refresh, logout, expiración
• Métricas de logins fallidos y sesiones conectadas a dashboards

Monitorización y Observabilidad

• Tasa de logins fallidos — más de 10 fallos/minuto por IP huele a credential stuffing; alertalo.
• Conteo de sesiones activas — un pico repentino puede ser un intento de fixation o un cliente mal configurado abriendo sesiones en bucle.
• Violaciones de sesiones concurrentes — expulsiones frecuentes por usuario pueden indicar credenciales compartidas.
• Ratio de logout — casi nadie cierra sesión; una proporción creciente puede indicar usuarios que sospechan que su cuenta está comprometida.

Consideraciones de Seguridad

Las específicas de sesiones — la lista genérica de OWASP vive en el checklist de seguridad de APIs:

• Fixation: regenerá el ID en el login, siempre.
• Hijacking por XSS: HttpOnly bloquea la lectura de la cookie; no arregla el XSS — combiná con prevención de XSS y CSP.
• Token de sesión en URLs: los query params terminan en logs de servidor, historial del navegador y headers Referer. Solo cookies.
• Atributos de cookie débiles: una cookie de sesión sin Secure/HttpOnly/SameSite son tres ataques esperando a ocurrir.
• Timeouts demasiado generosos: las sesiones robadas deberían morir rápido — 30 minutos de inactividad y 8 horas absolutas es un techo razonable.
• Brute force sin lockout: aplicá rate limit al login; los intentos no autenticados son baratos.
• Deserialización de datos de sesión: si el store guarda objetos serializados, validá el schema antes de usarlos.
• Eventos de auth invisibles: logueá logins, logouts, cambios de contraseña y expulsiones de sesión con user ID, IP y timestamp — los vas a querer durante un incidente.

Lecturas Adicionales

• OWASP Session Management Cheat Sheet — la referencia para flags de cookies, fixation y expiración.
• RFC 6265 — HTTP State Management Mechanism — la especificación de cookies, incluido SameSite.
• MDN: Set-Cookie — referencia de cookies atributo por atributo.
• Receta de autenticación JWT — la alternativa stateless.
• Autenticación de dos factores — la capa siguiente después de la seguridad de sesiones.
• Repo companion: ejemplos de session-management — el código Express, Spring y Python de esta página, ejecutable.