¿Cómo gestionas los tiempos de vida de sesiones y tokens (access vs refresh, rotación)?
Respuesta breve
Mantén los access tokens de corta duración (minutos) para que uno robado expire rápido, y usa refresh tokens de mayor duración para obtener nuevos access tokens sin volver a pedírselo al usuario. Rota los refresh tokens en cada uso y detecta la reutilización de un token ya consumido como señal de robo, revocando la cadena. El objetivo es equilibrar la limitación de la ventana de un token comprometido frente a no obligar a los usuarios a reautenticarse constantemente.
Los tokens y las sesiones son credenciales al portador: a quien tenga uno se le trata como el usuario. Por eso su tiempo de vida es una palanca de seguridad directa, y la entrevista quiere oír que entiendes el compromiso.
Access tokens vs refresh tokens
- Access token — se presenta en cada llamada a la API, a menudo un JWT sin estado. Hazlo de corta duración (típicamente 5–15 minutos). Si lo roban, la ventana del atacante es pequeña, y como es sin estado normalmente no puedes revocarlo a mitad de vida — la expiración corta es la mitigación.
- Refresh token — de mayor duración, custodiado con más cuidado, usado solo para emitir nuevos access tokens cuando el anterior expira. Esto mantiene al usuario con la sesión iniciada sin volver a pedírselo, mientras que el secreto de alto valor se intercambia con poca frecuencia y por el back channel.
Rotación de refresh tokens
La buena práctica (RFC 9700) son los refresh tokens de un solo uso con rotación: cada refresco devuelve un nuevo refresh token e invalida el anterior. El beneficio clave es la detección de robo — si se presenta de nuevo un refresh token previamente usado (ya invalidado), significa que dos partes tienen copias. El servidor lo trata como un compromiso y revoca toda la familia de tokens, cerrando la sesión del usuario en todas partes.
Sesiones: timeouts de inactividad vs absolutos
Para las sesiones del lado del servidor, combina un timeout de inactividad (expira tras la inactividad) con un timeout absoluto (un tope duro independientemente de la actividad). Vincula las sesiones a una cookie segura, HttpOnly, SameSite, y regenera el ID de sesión ante un cambio de privilegio (p. ej. tras el login) para frustrar la fijación.
Errores de almacenamiento
En los navegadores, prefiere las cookies HttpOnly sobre localStorage, que es legible por cualquier payload de XSS. Ofrece siempre un logout explícito y la revocación del lado del servidor para la credencial de larga duración.
Qué buscan los entrevistadores: que contrastes los tiempos de vida cortos de access frente a los más largos de refresh, que sepas explicar cómo la rotación convierte la reutilización de un refresh en una alarma de robo, y que sepas que los JWT sin estado intercambian revocabilidad por expiración corta.
Posibles preguntas de seguimiento
- ¿Cómo detecta un token robado la rotación de refresh tokens?
- ¿Por qué no puedes simplemente revocar un access token JWT sin estado a mitad de vida?
- ¿Dónde deberían almacenarse los tokens en un navegador y por qué no en localStorage?