Session Token în dezvoltarea aplicațiilor — ce este, principiul de funcționare și diferențele față de JWT

Ce este Session Token?

Session Token (identificator de sesiune) — este un șir unic pe care serverul îl generează și îl leagă de datele sesiunii după autentificarea utilizatorului. Tokenul nu conține nicio informație despre utilizator — este doar o cheie pentru datele stocate pe server. Această abordare se numește autentificare stateful: serverul stochează starea fiecărei sesiuni active și o verifică la fiecare cerere.

Datele sesiunii includ: identificatorul utilizatorului, ora autentificării, adresa IP, user-agent, lista de permisiuni (permissions), ora ultimei activități. Când clientul trimite o cerere cu session token, serverul găsește înregistrarea corespunzătoare în depozitul de sesiuni, verifică validitatea acesteia și extrage datele pentru procesarea cererii. Dacă înregistrarea sesiunii lipsește sau a expirat, serverul returnează o eroare de autentificare și solicită reautentificarea.

Conform datelor OWASP, 2025, session token rămâne standardul pentru aplicațiile care necesită revocarea imediată a accesului — de exemplu, în sistemele bancare și portalurile corporative, unde administratorul trebuie să poată încheia sesiunea utilizatorului instantaneu. În astfel de sisteme, session token asigură un control complet asupra accesului, de neatins pentru tokenurile stateless fără mecanisme suplimentare de blocare.

Cum funcționează Session Token

Procesul de funcționare începe atunci când clientul trimite datele de autentificare pe serverul de autentificare. Serverul verifică login-ul și parola, creează o înregistrare de sesiune în depozit (de obicei Redis sau bază de date) și returnează clientului un session token unic. Clientul salvează tokenul și îl transmite cu fiecare cerere ulterioară, iar serverul verifică de fiecare dată existența și validitatea sesiunii.

Sesiunea pe server și depozitul

Redis — cel mai popular depozit de sesiuni datorită stocării în memorie și suportului TTL (time-to-live). Fiecare sesiune este stocată ca o pereche cheie-valoare, unde cheia este session token, iar valoarea este un obiect JSON cu datele sesiunii. TTL elimină automat sesiunile expirate. Alternative: Memcached (doar memorie, fără salvare pe disc), PostgreSQL/MySQL (persistență, dar mai lent) și DynamoDB (pentru infrastructura AWS).

Exemplu de structură a sesiunii în Redis: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. Serverul actualizează lastAccess la fiecare cerere, ceea ce permite implementarea unui timeout de inactivitate — încheierea automată a sesiunii după o perioadă de inactivitate.

Cookie vs Header

Session Token poate fi transmis în două moduri: prin HTTP cookie sau prin antetul HTTP Authorization. Cookie — modul tradițional pentru aplicații web: serverul setează un cookie cu flagurile HttpOnly (inaccesibil JavaScript), Secure (doar HTTPS) și SameSite (protecție împotriva CSRF). Pentru aplicațiile mobile se folosește mai des antetul Authorization: Bearer <session_token>, deoarece mecanismul cookie nu este întotdeauna convenabil în clienții nativi.

Ciclul de viață al Session Token

Ciclul de viață al session token include trei etape: creare, menținerea sesiunii active și încheiere. Fiecare etapă necesită o configurare corectă a securității pentru a preveni scurgerea sau interceptarea tokenului.

Creare, stocare și ștergere

Creare — serverul generează un șir aleator criptografic sigur cu lungimea de 128–256 biți (de exemplu, prin SecureRandom în Java sau os.urandom în Python). Tokenul trebuie să fie imprevizibil — utilizarea UUID sau timestamp fără entropie nu este permisă. Stocare pe client: în iOS — Keychain, în Android — EncryptedSharedPreferences, în web — HttpOnly cookie. Ștergerea are loc la deconectare: clientul șterge tokenul din depozit, serverul șterge înregistrarea sesiunii din Redis. După deconectare, session token devine inutil — serverul nu va găsi înregistrarea corespunzătoare.

Conform datelor SANS Institute, 2025, implementarea corectă a încheierii sesiunii (deconectare cu curățare pe server) previne până la 70% dintre atacurile care folosesc tokenuri furate. Este esențial nu doar să ștergeți tokenul pe client, ci și să anulați sesiunea pe server.

Session Token vs JWT

Session Token și JWT reprezintă două abordări diferite ale autentificării. Session Token — stateful (serverul stochează starea), JWT — stateless (datele în interiorul tokenului). Alegerea între ele depinde de arhitectura aplicației și cerințele de securitate.

Când să alegeți Session Token

Session Token este preferat atunci când: este necesară revocarea imediată a sesiunilor (bancar, panouri de administrare), aplicația rulează pe unul sau mai multe servere cu Redis partajat, datele sesiunii sunt mari și nu încap în JWT, sau când echipa dorește să minimizeze riscul de scurgere a datelor prin decodificarea tokenului. În astfel de scenarii, session token asigură blocarea imediată a accesului la activitate suspectă — este suficient să ștergeți o înregistrare din Redis, iar toate sesiunile utilizatorului devin invalide.

Conform datelor Redis, 2025, utilizarea TTL la nivelul cheilor de sesiune (comanda EXPIRE) curăță automat sesiunile expirate, fără costuri suplimentare pentru sărciunile de fundal. Pentru sesiunile cu TTL de 1 oră și o încărcare de 10 000 de utilizatori simultani, Redis consumă aproximativ 1 GB de RAM la o dimensiune a sesiunii de 1 KB, ceea ce îl face eficient din punct de vedere economic pentru majoritatea aplicațiilor.

Securitatea Session Token

Securitatea session token se bazează pe două principii: tokenul trebuie să fie imprevizibil și protejat în timpul transmiterii și stocării. Amenințările principale — interceptarea tokenului (man-in-the-middle, XSS), predicția acestuia (generare slabă) și fixarea sesiunii (session fixation).

Protecția împotriva furtului de token

Protecția include: utilizarea HTTPS pentru toate cererile cu token, setarea unui TTL scurt al sesiunii (15–60 de minute de inactivitate), legarea sesiunii de IP și user-agent (verificare suplimentară la fiecare cerere), utilizarea flagurilor Secure și HttpOnly pentru cookie, rotația regulată a session token după operații sensibile (schimbarea parolei, creșterea drepturilor). OWASP recomandă, de asemenea, implementarea Gestionării sesiunilor cu invalidarea sesiunii vechi la crearea uneia noi după autentificare — acest lucru previne fixarea sesiunii.

Conform datelor OWASP ASVS, 2025, sesiunea trebuie legată de cel puțin doi factori: tokenul în sine (ce are clientul) și IP/user-agent (ce știe serverul). În cazul nepotrivirii acestor factori, serverul trebuie să încheie sesiunea și să solicite reautentificarea.

Exemplu de implementare în Kotlin

Mai jos este un exemplu de implementare pe server a session token în Kotlin folosind Spring Boot și Redis. Serverul generează un token criptografic sigur prin SecureRandom, salvează sesiunea în Redis cu TTL și o verifică la fiecare cerere. Codul demonstrează trei operații principale: crearea sesiunii, validarea și invalidarea.

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

Această implementare utilizează JedisPool pentru o conexiune thread-safe la Redis. Metoda createSession setează TTL de 1 oră (3600 de secunde) — după această perioadă, Redis va șterge automat înregistrarea. Metoda validateSession returnează null pentru sesiunile inexistente sau expirate, permițând serverului să proceseze corect o cerere cu un token invalid și să returneze HTTP 401.