Session Token nello sviluppo di applicazioni — cosa è, principio di funzionamento e differenze da JWT

Cos’è un Session Token?

Session Token (identificatore di sessione) è una stringa univoca che il server genera e associa ai dati di sessione dopo l’autenticazione dell’utente. Il token non contiene alcuna informazione dell’utente — è semplicemente una chiave per i dati memorizzati sul server. Questo approccio è chiamato autenticazione stateful: il server memorizza lo stato di ogni sessione attiva e lo verifica a ogni richiesta.

I dati di sessione includono: ID utente, ora di accesso, indirizzo IP, user-agent, elenco autorizzazioni, ora dell’ultima attività. Quando il cliente invia una richiesta con un session token, il server trova il record corrispondente nell’archivio delle sessioni, ne verifica la validità e recupera i dati per elaborare la richiesta. Se il record di sessione è assente o scaduto, il server restituisce un errore di autenticazione e richiede un nuovo accesso.

Secondo OWASP, 2025, il session token rimane lo standard per le applicazioni che richiedono una revoca immediata dell’accesso — ad esempio, nei sistemi bancari e nei portali aziendali dove un amministratore deve poter terminare la sessione di un utente istantaneamente. In questi sistemi, il session token fornisce un controllo completo sull’accesso che è irraggiungibile per i token stateless senza meccanismi di blocco aggiuntivi.

Come funziona un Session Token

Il processo inizia quando il cliente invia le credenziali al server di autenticazione. Il server verifica l’utente e la password, crea un record di sessione nell’archivio (di solito Redis o un database) e restituisce un session token univoco al cliente. Il cliente salva il token e lo invia con ogni richiesta successiva, e il server verifica ogni volta l’esistenza e la validità della sessione.

Memorizzazione della sessione server

Redis è l’archivio di sessioni più popolare grazie alla memorizzazione in memoria e al supporto TTL (time-to-live). Ogni sessione è memorizzata come coppia chiave-valore, dove la chiave è il session token e il valore è un oggetto JSON con i dati di sessione. Il TTL rimuove automaticamente le sessioni scadute. Alternative: Memcached (solo memoria, senza persistenza su disco), PostgreSQL/MySQL (persistenti ma più lenti) e DynamoDB (per infrastruttura AWS).

Esempio di struttura di sessione in Redis: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. Il server aggiorna lastAccess a ogni richiesta, consentendo di implementare un timeout di inattività — terminazione automatica della sessione dopo un periodo senza attività.

Cookie vs Header

Session Token può essere trasmesso in due modi: tramite cookie HTTP o tramite l’header HTTP Authorization. I cookie sono il metodo tradizionale per le applicazioni web: il server imposta un cookie con i flag HttpOnly (inaccessibile da JavaScript), Secure (solo HTTPS) e SameSite (protezione CSRF). Per le applicazioni mobili, viene utilizzato più comunemente l’header Authorization: Bearer <session_token>, poiché il meccanismo dei cookie non è sempre conveniente nei client nativi.

Ciclo di vita del Session Token

Il ciclo di vita del session token comprende tre fasi: creazione, mantenimento della sessione attiva e terminazione. Ogni fase richiede una configurazione di sicurezza adeguata per prevenire la fuga o l’intercettazione del token.

Creazione, archiviazione ed eliminazione

Creazione — il server genera una stringa casuale crittograficamente sicura di 128–256 bit (ad esempio, tramite SecureRandom in Java o os.urandom in Python). Il token deve essere imprevedibile — l’uso di UUID o timestamp senza entropia non è accettabile. Archiviazione sul client: su iOS — Keychain, su Android — EncryptedSharedPreferences, sul web — cookie HttpOnly. Eliminazione avviene al logout: il cliente rimuove il token dall’archivio, il server elimina il record di sessione da Redis. Dopo il logout, il session token diventa inutile — il server non trova un record corrispondente.

Secondo SANS Institute, 2025, la corretta implementazione della terminazione della sessione (logout con pulizia lato server) previene fino al 70% degli attacchi con token rubati. È fondamentale non solo eliminare il token sul client, ma anche invalidare la sessione sul server.

Session Token vs JWT

Session Token e JWT rappresentano due approcci diversi all’autenticazione. Session Token è stateful (il server memorizza lo stato), JWT è stateless (i dati all’interno del token). La scelta tra di essi dipende dall’architettura dell’applicazione e dai requisiti di sicurezza.

Quando scegliere Session Token

Session Token è preferibile quando: è richiesta la revoca istantanea delle sessioni (servizi bancari, pannelli di amministrazione), l’applicazione funziona su uno o più server con Redis condiviso, i dati di sessione sono grandi e non entrano in JWT, o il team vuole minimizzare il rischio di fuga di dati attraverso la decodifica del token. In questi scenari, il session token fornisce un blocco immediato dell’accesso in caso di attività sospetta — basta eliminare un record da Redis per rendere tutte le sessioni dell’utente non valide.

Secondo Redis, 2025, l’uso di TTL a livello di chiavi di sessione (comando EXPIRE) pulisce automaticamente le sessioni scadute senza overhead per le attività in background. Per sessioni con TTL di 1 ora e un carico di 10.000 utenti simultanei, Redis consuma circa 1 GB di RAM con una dimensione di sessione di 1 KB, rendendolo economicamente efficiente per la maggior parte delle applicazioni.

Sicurezza del Session Token

La sicurezza del session token si basa su due principi: il token deve essere imprevedibile e protetto durante la trasmissione e l’archiviazione. Le principali minacce sono l’intercettazione del token (man-in-the-middle, XSS), la sua previsione (generazione debole) e il fissaggio della sessione (session fixation).

Protezione contro il furto del token

La protezione include: uso di HTTPS per tutte le richieste con token, impostazione di un TTL breve di sessione (15–60 minuti di inattività), collegamento della sessione a IP e user-agent (verifica aggiuntiva a ogni richiesta), uso dei flag Secure e HttpOnly per i cookie e rotazione periodica del session token dopo operazioni sensibili (cambio password, escalation privilegi). OWASP raccomanda anche di implementare la Gestione delle Sessioni con invalidamento della sessione vecchia quando se ne crea una nuova dopo il login — questo previene il session fixation.

Secondo OWASP ASVS, 2025, una sessione deve essere legata ad almeno due fattori: il token stesso (ciò che il cliente possiede) e l’IP/user-agent (ciò che il server sa). Se questi fattori non coincidono, il server deve terminare la sessione e richiedere una nuova autenticazione.

Esempio di implementazione in Kotlin

Di seguito è riportato un esempio di implementazione lato server di session token in Kotlin utilizzando Spring Boot e Redis. Il server genera un token crittograficamente sicuro tramite SecureRandom, salva la sessione in Redis con TTL e la verifica a ogni richiesta. Il codice dimostra tre operazioni principali: creazione della sessione, convalida e invalidamento.

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)
    }
}

Questa implementazione utilizza JedisPool per una connessione thread-safe a Redis. Il metodo createSession imposta un TTL di 1 ora (3600 secondi) — dopo questo periodo, Redis eliminerà automaticamente il record. Il metodo validateSession restituisce null per sessioni inesistenti o scadute, consentendo al server di gestire correttamente una richiesta con un token non valido e restituire HTTP 401.