Seguridad de la sesion
Esta seccion explica como ATLAS protege las sesiones de los usuarios contra robos de credenciales o de tokens. Esta pensada para un publico no tecnico: no hay rutas de archivos, ni configuraciones, ni codigo. Solo el modelo mental de como funciona la proteccion.
Modelo general
Cuando un usuario inicia sesion, ATLAS no le devuelve el token al codigo de la pagina. La proteccion se construye sobre cuatro capas que trabajan juntas. Ninguna es magica por si sola; el conjunto es el que hace la diferencia.
1. Tokens fuera del alcance del navegador
Los tokens viajan en cookies HttpOnly: una variante especial de cookie que el navegador guarda pero no expone al codigo de la pagina. La consola de desarrolladores puede ver el nombre de la cookie pero no su valor, y ninguna extension del navegador ni script inyectado en la pagina puede leerlas.
Esto significa que, aunque alguien tenga acceso fisico al equipo o consiga ejecutar codigo dentro de la pagina, no puede copiar los tokens para reutilizarlos en otra maquina.
2. Deteccion de reutilizacion del refresh token
ATLAS maneja dos credenciales por sesion:
- Un access token corto, que autoriza cada peticion a la API.
- Un refresh token, que permite renovar el access token sin pedirle la contrasena al usuario.
El refresh token funciona como una llave de un solo uso: cada vez que se usa, el sistema lo da de baja y emite uno nuevo.
Si en algun momento alguien presenta una llave que ya fue consumida, ATLAS interpreta que la cadena fue comprometida y revoca todas las sesiones activas del usuario en el acto. El atacante queda fuera y el usuario legitimo es obligado a iniciar sesion otra vez, con su contrasena.
3. Huella digital del navegador
Al emitir un access token, ATLAS calcula una huella corta del navegador del usuario y la incrusta como parte del token. En cada peticion posterior, el servidor compara la huella del token con la del navegador que lo presenta. Si no coinciden, la peticion es rechazada.
Esto significa que un access token solo es valido si se usa desde el mismo navegador y sistema operativo en el que fue emitido. Intentar reutilizarlo desde otro dispositivo devuelve un error de autenticacion.
4. Vida util corta y cierre al cerrar el navegador
- El access token vive 15 minutos. Pasado ese tiempo, debe renovarse usando el refresh token, lo que activa la deteccion de reutilizacion (capa 2).
- En navegadores web, el refresh token es una cookie de sesion: el navegador la elimina automaticamente cuando el proceso del navegador se cierra. Reabrir el navegador exige iniciar sesion de nuevo.
- Adicionalmente, un marcador interno en el almacenamiento de la pestana refuerza este comportamiento: si la pagina se carga sin ese marcador, ATLAS asume que es una sesion fresca y redirige al login.
El comportamiento es similar al de un home banking: cerrar el navegador equivale a cerrar sesion.
Por que no se ata la sesion a la IP
Una proteccion comun seria atar la sesion a la direccion IPv4 del usuario y rechazar cualquier peticion desde otra IP. ATLAS no lo aplica porque tiene demasiados falsos positivos en uso real:
- Las redes moviles (4G/5G) cambian la IP con frecuencia.
- Las VPN corporativas y los proxies presentan IPs rotativas.
- Cambiar de WiFi a datos moviles cambia la IP.
- En CGNAT, miles de usuarios comparten una sola IP publica.
Las cuatro capas anteriores cubren el mismo riesgo sin desloguear usuarios legitimos. La IP queda registrada en los logs de auditoria, pero no se usa como criterio de bloqueo.
Resumen para el usuario final
- ATLAS se comporta como un home banking: si cerras el navegador, te vuelve a pedir credenciales.
- Si tu sesion queda abierta en otra computadora, cuando vuelvas a entrar desde la tuya el sistema lo detecta y obliga al otro acceso a iniciar sesion otra vez.
- Las cuentas no se pueden secuestrar copiando tokens del inspector del navegador: esos valores no estan accesibles para la pagina.