Sesiones y rotación de tokens
Cuando un usuario inicia sesión en una aplicación impulsada por Auris, el sistema crea una sesión. Esta sesión es el registro autoritativo del estado de autenticación del usuario. Comprender cómo funcionan las sesiones, cómo rotan los tokens y cómo Auris detecta el robo de tokens es esencial para crear aplicaciones seguras.
¿Qué es una sesión en Auris?
Una sesión en Auris es un registro de servidor almacenado en la base de datos (vía Prisma), no una cookie del lado del cliente ni un token. Cada sesión contiene:
| Campo | Descripción |
|---|---|
id | Identificador único de sesión |
userId | El usuario autenticado |
sessionToken | Un token opaco almacenado en una cookie httpOnly del cliente |
accessToken | El access token emitido más recientemente (JWT) |
refreshToken | El refresh token emitido más recientemente (cadena opaca) |
tokenFamily | Identificador que vincula todos los refresh tokens en la cadena de rotación de esta sesión |
createdAt | Cuándo se creó la sesión (para expiración absoluta) |
lastActiveAt | Cuándo se usó la sesión por última vez (para expiración deslizante) |
expiresAt | Cuándo expira la sesión |
ipAddress | Dirección IP del inicio de sesión original |
userAgent | Identificador del navegador/dispositivo del inicio de sesión original |
acr | Authentication Context Class Reference (nivel de fortaleza de autenticación) |
amr | Authentication Methods Reference (qué factores se usaron) |
La distinción clave respecto a muchos otros proveedores de autenticación: las sesiones de Auris son autoritativas en el servidor. El servidor siempre sabe qué sesiones existen, cuáles están activas, y puede revocar cualquier sesión instantáneamente.
Ciclo de vida de la sesión
Creación de sesión
Cuando la autenticación tiene éxito (después de todos los factores incluyendo MFA, comprobaciones de riesgo adaptativo y hooks del motor de Actions), Auris:
- Crea un registro
OAuthSessionen la base de datos - Genera un
sessionTokenaleatorio y lo establece como cookiehttpOnly(TTL de 30 minutos, renovado en cada uso) - Emite un access token (JWT firmado) con los claims del usuario, roles y custom claims
- Emite un refresh token (cadena opaca con prefijo
rt_) - Asigna un identificador
tokenFamilyque vincula todos los futuros refresh tokens de esta sesión
Uso activo
Durante la vida activa de la sesión, el cliente envía el access token en cada solicitud a la API. El resource server valida la firma JWT localmente (vía JWKS) sin contactar a Auris. No se realiza ninguna búsqueda en base de datos para la validación del access token.
Refresco
Cuando el access token expira, el cliente envía el refresh token al endpoint de tokens. Auris:
- Busca el refresh token en la base de datos
- Valida que no haya sido usado antes (comprobación de rotación)
- Valida que la sesión no haya expirado
- Invalida el refresh token antiguo (lo marca como usado)
- Emite un nuevo access token y un nuevo refresh token
- Actualiza
lastActiveAten la sesión (reinicia la ventana deslizante)
Terminación
Las sesiones terminan mediante varios mecanismos:
| Mecanismo | Cuándo ocurre | Efecto |
|---|---|---|
| Cierre de sesión explícito | El usuario hace clic en “Cerrar sesión” | Sesión eliminada, todos los tokens de esta sesión invalidados |
| Expiración deslizante | Sin refresco dentro de la ventana de inactividad | La sesión expira |
| Expiración absoluta | La sesión ha estado activa más que el máximo absoluto | La sesión expira independientemente de la actividad |
| Revocación por administrador | El admin revoca la sesión desde la Consola | Sesión eliminada inmediatamente |
| Detección de reutilización | Se presenta un refresh token ya usado | Toda la familia de tokens es revocada |
| Acción de cuenta | Usuario deshabilitado, eliminado o contraseña cambiada | Todas las sesiones del usuario son revocadas |
Rotación de refresh tokens
La rotación de refresh tokens es un mecanismo de seguridad donde cada refresco de token exitoso invalida el refresh token antiguo y emite uno nuevo. Auris implementa la rotación por defecto sin opción de desactivarla.
Detección de reutilización
Si se presenta un refresh token ya usado, Auris:
- Detecta que el token ya fue marcado como utilizado
- Concluye que un atacante puede tener un refresh token válido (ya que el token legítimo debería haber sido reemplazado)
- Revoca toda la familia de tokens — todos los refresh tokens que pertenecen a la misma sesión quedan invalidados
La revocación de familia de tokens puede afectar a usuarios legítimos si el mismo refresh token se usa en múltiples pestañas simultáneamente. Los SDK de Auris previenen esto mediante cola de solicitudes — solo una solicitud de refresco se ejecuta a la vez por sesión.
Vinculación y seguridad de sesiones
Detección de cambio de IP
Auris registra la IP del inicio de sesión original. Si el motor de riesgo detecta un cambio de IP significativo (diferente país), esto contribuye a la puntuación de riesgo para el siguiente refresco de token.
Validación del User Agent
El user agent del inicio de sesión original se registra. Los cambios en el user agent contribuyen a la puntuación de riesgo.
Revocación a través de la Consola
Los administradores pueden ver y revocar sesiones individuales para cualquier usuario desde la Consola de administración → Usuarios → [usuario] → Sesiones. La revocación es instantánea — el siguiente intento de uso del access token devolverá 401 SESSION_REVOKED.