Autenticación web en la práctica: contraseñas, JWT y cookies seguras

La autenticación es la capa de seguridad donde empiezan la mayoría de las brechas — no porque sea difícil de entender, sino porque implica una larga cadena de decisiones pequeñas, cada una individualmente razonable, y juntas o sólidas o sutilmente rotas. Esta guía recorre el flujo completo: desde cómo se almacenan las contraseñas hasta por qué los atributos específicos de una cookie importan más de lo que parece.

1. Cómo almacenar contraseñas correctamente

La primera regla: nunca guardar una contraseña. Guardar solo su hash. El cifrado se puede revertir si tienes la clave — una base de datos con contraseñas cifradas filtrada es un desastre esperando ocurrir. Un hash no se puede revertir: verificas una contraseña hasheando la entrada y comparándola con el valor almacenado, pero nunca puedes ir en sentido contrario.

Usa Argon2id (la recomendación actual de OWASP) o bcrypt — nunca MD5 ni SHA-256. Las funciones hash de propósito general están diseñadas para ser rápidas. Las funciones de hash para contraseñas están diseñadas para ser lentas. Esos 200ms intencionales en tu servidor se convierten en miles de años si un atacante intenta fuerza bruta sobre una base de datos filtrada. Combínalas con un salt — un valor aleatorio único por usuario — para que dos cuentas con la misma contraseña produzcan hashes completamente distintos. Esto hace inútiles los ataques de rainbow tables precomputadas.

2. Después del login: sesiones vs. JWT

Una vez verificadas las credenciales, el servidor necesita una forma de reconocer al usuario en cada petición siguiente. Dos enfoques dominan: las sesiones, donde el servidor guarda el estado, y el JWT, donde el token lleva el estado.

Con sesiones, el servidor guarda un registro — en memoria, Redis o una base de datos — y envía al cliente solo un ID de sesión en una cookie. La revocación es inmediata: elimina el registro y el usuario queda desconectado. La contrapartida es que todos tus servidores necesitan acceso al mismo almacén de sesiones, lo que complica el escalado horizontal.

Con JWT, el servidor firma un token autocontenido y lo envía al cliente. Las peticiones futuras devuelven el token, y el servidor valida la firma localmente — sin consultar la base de datos. Esto escala sin fricción entre múltiples instancias. La contrapartida es la revocación: una vez emitido, un JWT es válido hasta que expira, sin ningún registro central que eliminar.

3. JWT en la práctica

Un JWT tiene tres partes separadas por puntos: un header (algoritmo y tipo de token), un payload (claims: ID de usuario, roles, expiración) y una firma. El header y el payload están codificados en base64url — no cifrados. Cualquiera que obtenga el token puede leerlos. Nunca pongas datos sensibles en el payload.

La firma es en lo que confía el servidor. Con HS256, el mismo secreto firma y verifica. Con RS256, una clave privada firma y la clave pública verifica — útil cuando varios servicios necesitan validar tokens sin compartir secretos. En cualquier caso, la verificación es local y no requiere ninguna consulta externa.

La debilidad estructural del JWT es la revocación. Una vez emitido, el token es válido hasta que expira. La solución estándar: emitir JWTs de vida corta (15 minutos es habitual) combinados con un refresh token de vida larga almacenado en la base de datos. El JWT gestiona la autenticación petición a petición; cuando expira, el cliente presenta el refresh token para obtener un par nuevo. La regla crítica: rotar el refresh token en cada uso. Si el mismo refresh token se presenta dos veces, trátalo como una brecha — revoca todas las sesiones de ese usuario de inmediato.

El flujo completo de JWT: login, peticiones protegidas y renovación con rotación.

4. Dónde almacenar el token

El debate entre localStorage y cookies se resuelve con una pregunta: ¿puede JavaScript leerlo? localStorage es completamente accesible para cualquier script que corra en tu página — tu código, pero también un asset CDN comprometido, una librería de analítica de terceros o un payload XSS. Un único punto de inyección en cualquier parte de tu stack expone el token.

Una cookie HttpOnly es invisible para JavaScript por diseño. El navegador la adjunta automáticamente a cada petición que coincida con el dominio, pero ningún script puede acceder a ella ni exfiltrarla. Añade los atributos correctos y cierras los dos vectores de ataque más comunes:

Cada atributo cierra un vector de ataque específico. Los cuatro juntos forman una línea base sólida.

5. Capas de seguridad adicionales

Estos fundamentos cubren la mayor parte del camino. Unas pocas capas adicionales completan el panorama:

• MFA — un segundo factor (TOTP, llave física o passkey) garantiza que una contraseña filtrada sola no sea suficiente para entrar.
• Rate limiting — limita los intentos de login a 5–10 por minuto para hacer inviable la fuerza bruta.
• Mensajes de error genéricos — "Credenciales inválidas" en lugar de "Usuario no encontrado" niega a los atacantes información sobre qué emails existen.
• OAuth2/OIDC — delega la autenticación completamente a un proveedor de confianza; tu app nunca maneja la contraseña del usuario.