Session Token en el desarrollo de aplicaciones — qué es, principio de funcionamiento y diferencias con JWT

¿Qué es un Session Token?

Session Token (identificador de sesión) es una cadena única que el servidor genera y asocia con los datos de la sesión tras la autenticación del usuario. El token no contiene ninguna información del usuario — es simplemente una clave para los datos almacenados en el servidor. Este enfoque se denomina autenticación stateful: el servidor almacena el estado de cada sesión activa y lo verifica en cada solicitud.

Los datos de la sesión incluyen: identificador de usuario, hora de inicio de sesión, dirección IP, user-agent, lista de permisos, hora de la última actividad. Cuando el cliente envía una solicitud con un session token, el servidor encuentra el registro correspondiente en el almacén de sesiones, comprueba su validez y recupera los datos para procesar la solicitud. Si el registro de la sesión falta o ha expirado, el servidor devuelve un error de autenticación y solicita un nuevo inicio de sesión.

Según OWASP, 2025, el session token sigue siendo el estándar para aplicaciones que requieren revocación inmediata del acceso — por ejemplo, en sistemas bancarios y portales corporativos donde un administrador debe poder finalizar la sesión de un usuario al instante. En estos sistemas, el session token proporciona un control total sobre el acceso que es inalcanzable para los tokens stateless sin mecanismos de bloqueo adicionales.

Cómo funciona un Session Token

El proceso comienza cuando el cliente envía las credenciales al servidor de autenticación. El servidor verifica el usuario y la contraseña, crea un registro de sesión en el almacén (generalmente Redis o una base de datos) y devuelve un session token único al cliente. El cliente guarda el token y lo envía con cada solicitud posterior, y el servidor comprueba la existencia y validez de la sesión cada vez.

Sesión del servidor y almacenamiento

Redis es el almacén de sesiones más popular gracias al almacenamiento en memoria y al soporte de TTL (tiempo de vida). Cada sesión se almacena como un par clave-valor, donde la clave es el session token y el valor es un objeto JSON con los datos de la sesión. El TTL elimina automáticamente las sesiones caducadas. Alternativas: Memcached (solo memoria, sin persistencia en disco), PostgreSQL/MySQL (persistentes pero más lentos) y DynamoDB (para infraestructura AWS).

Ejemplo de estructura de sesión en Redis: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. El servidor actualiza lastAccess en cada solicitud, lo que permite implementar un tiempo de espera por inactividad — finalización automática de la sesión tras un período sin actividad.

Cookie vs Cabecera

Session Token puede transmitirse de dos formas: mediante una cookie HTTP o mediante la cabecera HTTP Authorization. Las cookies son el método tradicional para aplicaciones web: el servidor establece una cookie con las banderas HttpOnly (inaccesible desde JavaScript), Secure (solo HTTPS) y SameSite (protección contra CSRF). Para aplicaciones móviles, se usa más comúnmente la cabecera Authorization: Bearer <session_token>, ya que el mecanismo de cookies no siempre es conveniente en clientes nativos.

Ciclo de vida del Session Token

El ciclo de vida del session token incluye tres etapas: creación, mantenimiento de la sesión activa y finalización. Cada etapa requiere una configuración de seguridad adecuada para evitar la filtración o interceptación del token.

Creación, almacenamiento y eliminación

Creación — el servidor genera una cadena aleatoria criptográficamente segura de 128–256 bits (por ejemplo, mediante SecureRandom en Java o os.urandom en Python). El token debe ser impredecible — el uso de UUID o timestamp sin entropía no es aceptable. Almacenamiento en el cliente: en iOS — Keychain, en Android — EncryptedSharedPreferences, en la web — cookie HttpOnly. Eliminación ocurre al cerrar sesión: el cliente elimina el token del almacenamiento, el servidor elimina el registro de la sesión de Redis. Tras cerrar sesión, el session token se vuelve inútil — el servidor no encontrará un registro correspondiente.

Según SANS Institute, 2025, la implementación correcta de la finalización de sesión (cierre de sesión con limpieza en el servidor) previene hasta el 70% de los ataques con tokens robados. Es fundamental no solo eliminar el token en el cliente, sino también invalidar la sesión en el servidor.

Session Token vs JWT

Session Token y JWT representan dos enfoques diferentes para la autenticación. Session Token es stateful (el servidor almacena el estado), JWT es stateless (los datos dentro del token). La elección entre ellos depende de la arquitectura de la aplicación y los requisitos de seguridad.

Cuándo elegir Session Token

Session Token es preferible cuando: se requiere revocación instantánea de sesiones (banca, paneles de administración), la aplicación funciona en uno o varios servidores con Redis compartido, los datos de sesión son grandes y no caben en JWT, o el equipo quiere minimizar el riesgo de filtración de datos mediante decodificación del token. En estos escenarios, el session token proporciona un bloqueo inmediato del acceso ante actividad sospechosa — basta con eliminar un registro de Redis para que todas las sesiones del usuario queden invalidadas.

Según Redis, 2025, el uso de TTL a nivel de claves de sesión (comando EXPIRE) limpia automáticamente las sesiones caducadas sin sobrecarga en tareas en segundo plano. Para sesiones con TTL de 1 hora y una carga de 10 000 usuarios concurrentes, Redis consume aproximadamente 1 GB de RAM con un tamaño de sesión de 1 KB, lo que lo hace rentable para la mayoría de las aplicaciones.

Seguridad del Session Token

La seguridad del session token se basa en dos principios: el token debe ser impredecible y estar protegido durante la transmisión y el almacenamiento. Las principales amenazas son la interceptación del token (man-in-the-middle, XSS), su predicción (generación débil) y la fijación de sesión (session fixation).

Protección contra el robo del token

La protección incluye: uso de HTTPS para todas las solicitudes con token, establecimiento de un TTL corto de sesión (15–60 minutos de inactividad), vinculación de la sesión a IP y user-agent (verificación adicional en cada solicitud), uso de las banderas Secure y HttpOnly para cookies, y rotación periódica del session token tras operaciones sensibles (cambio de contraseña, escalada de privilegios). OWASP también recomienda implementar Gestión de Sesiones con invalidación de la sesión anterior al crear una nueva tras el inicio de sesión — esto previene la fijación de sesión.

Según OWASP ASVS, 2025, una sesión debe estar vinculada al menos a dos factores: el propio token (lo que tiene el cliente) y la IP/user-agent (lo que sabe el servidor). Si estos factores no coinciden, el servidor debe finalizar la sesión y solicitar una nueva autenticación.

Ejemplo de implementación en Kotlin

A continuación se muestra un ejemplo de implementación de session token en el servidor con Kotlin utilizando Spring Boot y Redis. El servidor genera un token criptográficamente seguro mediante SecureRandom, guarda la sesión en Redis con TTL y la verifica en cada solicitud. El código demuestra tres operaciones principales: creación de sesión, validación e invalidación.

data class Session(
    val userId: Long,
    val role: String,
    val createdAt: Long,
    val lastAccess: Long
)

object SessionManager {
    private val redis = JedisPool("localhost", 6379)

    fun createSession(userId: Long, role: String): String {
        val token = generateSecureToken()
        val session = Session(userId, role, now(), now())
        redis.resource.use { conn ->
            conn.setex("session:$token", 3600, toJson(session))
        }
        return token
    }

    fun validateSession(token: String): Session? {
        redis.resource.use { conn ->
            val json = conn.get("session:$token") ?: return null
            return fromJson(json)
        }
    }

    fun invalidateSession(token: String) {
        redis.resource.use { it.del("session:$token") }
    }

    private fun generateSecureToken(): String {
        val bytes = ByteArray(32)
        SecureRandom().nextBytes(bytes)
        return Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)
    }
}

Esta implementación utiliza JedisPool para una conexión segura a Redis en entornos multihilo. El método createSession establece un TTL de 1 hora (3600 segundos) — tras este período, Redis eliminará automáticamente el registro. El método validateSession devuelve null para sesiones inexistentes o caducadas, lo que permite al servidor manejar correctamente una solicitud con un token no válido y devolver HTTP 401.