Le quité el acceso y sigue dentro: una sesión no es lo mismo que un permiso

Le quitaste el permiso a un usuario. Puede que hayas desactivado la cuenta entera. Después notas que esa persona todavía puede hacer cosas.

No hay nada roto. Iniciar sesión y estar autorizado son dos momentos distintos, y entre ellos hay un hueco.

El inicio de sesión ocurre una vez, el permiso se pregunta cada vez

Cuando inicias sesión, el sistema te entrega un billete. El billete dice: esta persona demostró quién es, y este billete vale hasta tal hora.

El permiso es una pregunta aparte, que se repite en cada petición. Pero en la práctica muchos sistemas toman en el momento del inicio de sesión una copia del mapa de permisos, por velocidad, y usan esa copia un rato.

De ahí nacen dos retrasos.

El primero: cuando quitas un permiso, una sesión abierta puede seguir llevando esa copia. El cambio solo le llega cuando la sesión se renueva.

El segundo, y más importante: borrar o desactivar al usuario no rompe el billete que tiene en la mano. El billete se basta a sí mismo y sigue válido hasta que caduca.

La regla: quitar el acceso no es terminar la sesión

Son dos acciones distintas, y hacer solo la primera deja una ventana abierta detrás de ti.

La ventana no es infinita; un billete no vale un día entero. Pero tampoco es cero, y en una situación urgente "se cerrará dentro de poco" no es una respuesta suficiente.

Cuando alguien se va, o una contraseña es sospechosa

Haz tres cosas, en orden.

Quita el permiso. Desactiva también la cuenta si procede.

Cambia la contraseña. Eso cierra el camino para conseguir un billete nuevo que sustituya al que tiene. Quitar solo el permiso no lo hace.

Elimina los tokens de acceso aparte. Este es el paso que más se salta. Un token no es una sesión: no caduca solo, vive hasta que tú lo borras. Cambiar la contraseña de un usuario no invalida sus tokens. Al eliminar un usuario, comprueba aparte qué fue de sus tokens.

Y cerremos un malentendido: la verificación en dos pasos no te ayuda aquí. Protege el momento del inicio de sesión. Sobre una sesión ya abierta no tiene nada que decir.

El sentido contrario: por qué me cierra la sesión constantemente

Es la otra cara del mismo mecanismo.

El billete tiene una vida limitada, y la interfaz lo renueva con regularidad mientras estás en la pestaña. Cierras la pestaña y vuelves horas después: no hubo renovación, el billete está muerto, y se te pide entrar de nuevo. Eso no es una avería.

La segunda causa, menos conocida, es más interesante: el reloj de la máquina. Un billete lleva una marca de tiempo. Si el reloj del servidor se desvía, un billete recién emitido puede parecer venido del futuro o caducado hace mucho. El síntoma desconcierta: la contraseña es correcta, el acceso parece aceptado, y la sesión cae justo después. A nadie se le ocurre buscar un problema de reloj en el lado de la identidad, pero búscalo.

Qué hace Atlas

En Atlas la cookie que va al navegador no es el billete de verdad. El navegador lleva solo un identificador aleatorio sin significado; el billete real se queda en el servidor.

La diferencia es concreta: aunque un fallo del navegador lea la cookie, no se lleva el billete en sí, así que no puede llevarlo a otro sitio y usarlo allí. Lo único que puede hacer es actuar desde ese navegador mientras esa sesión viva. No es riesgo cero, pero estrecha el alcance de la amenaza.

Las sesiones abiertas se escriben en disco, de modo que cuando el producto se actualiza no se echa a nadie. La escritura se hace a propósito en un solo paso: si el archivo hubiera quedado a medio escribir, entonces, aunque el lado que lee lo tolere, todas las sesiones abiertas se habrían caído.

Lo que de verdad merece contarse es un fallo hallado aquí midiendo.

Los registros de sesión caducados se limpiaban solo de la memoria, no del archivo. Se miró una máquina en servicio: en el archivo había cinco registros caducados, cada uno con un billete dentro. Habrían seguido ahí hasta el siguiente inicio de sesión, porque ninguna otra cosa escribía nunca ese archivo.

La intención del código ya era no conservarlos. Lo único que faltaba era el paso de escritura.

La lección vale para cualquiera que escriba código de seguridad: olvidar tiene dos lugares. Lo que se quitó de la memoria no se quitó del disco, y de los dos el del disco siempre vive más. Cuando decides que algo no debe conservarse, la segunda pregunta es siempre la misma: ¿dónde se conserva?