Session Token az alkalmazásfejlesztésben — mi ez, működési elv és különbségek a JWT-től

Mi az a Session Token?

Session Token (munkamenet-azonosító) — egy egyedi karaktersorozat, amelyet a szerver generál és a munkamenet adataihoz kapcsol a felhasználó hitelesítése után. A token nem tartalmaz semmilyen információt a felhasználóról — ez csak egy kulcs a szerveren tárolt adatokhoz. Ezt a megközelítést stateful hitelesítésnek nevezik: a szerver tárolja minden aktív munkamenet állapotát, és minden kérésnél ellenőrzi azt.

A munkamenet adatai magukban foglalják: a felhasználó azonosítóját, a bejelentkezés idejét, IP-címet, user-agentet, engedélyek listáját (permissions), az utolsó tevékenység idejét. Amikor a kliens session token-nel küld kérést, a szerver megtalálja a megfelelő rekordot a munkamenet-tárolóban, ellenőrzi annak érvényességét, és kinyeri az adatokat a kérés feldolgozásához. Ha a munkamenet rekordja hiányzik vagy lejárt, a szerver hitelesítési hibát ad vissza, és új bejelentkezést kér.

A OWASP, 2025 adatai szerint a session token továbbra is szabvány az olyan alkalmazások számára, amelyek azonnali hozzáférés-visszavonást igényelnek — például bankrendszerekben és vállalati portálokon, ahol a rendszergazdának képesnek kell lennie a felhasználó munkamenetének azonnali befejezésére. Az ilyen rendszerekben a session token teljes hozzáférés-ellenőrzést biztosít, ami elérhetetlen a stateless tokenek számára további blokkoló mechanizmusok nélkül.

Hogyan működik a Session Token

A működési folyamat azzal kezdődik, hogy a kliens hitelesítő adatokat küld a hitelesítési szerverre. A szerver ellenőrzi a felhasználónevet és jelszót, létrehoz egy munkamenet-rekordot a tárolóban (általában Redis vagy adatbázis), és visszaküldi a kliensnek az egyedi session token-t. A kliens elmenti a tokent, és minden további kéréssel együtt elküldi, a szerver pedig minden alkalommal ellenőrzi a munkamenet létezését és érvényességét.

Szerveroldali munkamenet és tároló

Redis — a legnépszerűbb munkamenet-tároló a memóriabeli tárolásnak és a TTL (time-to-live) támogatásának köszönhetően. Minden munkamenet kulcs-érték párosként tárolódik, ahol a kulcs a session token, az érték pedig egy JSON objektum a munkamenet adataival. A TTL automatikusan eltávolítja a lejárt munkameneteket. Alternatívák: Memcached (csak memória, lemezre mentés nélkül), PostgreSQL/MySQL (perzisztencia, de lassabb) és DynamoDB (AWS infrastruktúrához).

Példa a munkamenet szerkezetére Redis-ben: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. A szerver minden kérésnél frissíti a lastAccess-t, ami lehetővé teszi az inaktivitási időtúllépés megvalósítását — a munkamenet automatikus befejezését inaktivitási időszak után.

Cookie vs Header

Session Token kétféleképpen továbbítható: HTTP cookie-n vagy HTTP Authorization fejlécen keresztül. Cookie — a hagyományos módszer webalkalmazásokhoz: a szerver beállít egy cookie-t HttpOnly (JavaScript számára nem elérhető), Secure (csak HTTPS) és SameSite (CSRF elleni védelem) jelzőkkel. Mobilos alkalmazásokhoz gyakrabban használják az Authorization: Bearer <session_token> fejlécet, mivel a cookie mechanizmus nem mindig kényelmes natív kliensekben.

A Session Token életciklusa

A session token életciklusa három szakaszból áll: létrehozás, aktív munkamenet fenntartása és befejezés. Minden szakasz megfelelő biztonsági konfigurációt igényel a token kiszivárgásának vagy elfogásának megelőzéséhez.

Létrehozás, tárolás és törlés

Létrehozás — a szerver egy kriptográfiailag biztonságos véletlenszerű karaktersorozatot generál 128–256 bit hosszan (pl. SecureRandom segítségével Java-ban vagy os.urandom segítségével Python-ban). A tokennek kiszámíthatatlannak kell lennie — entrópia nélküli UUID vagy időbélyeg használata nem megengedett. Tárolás a kliens oldalon: iOS-ben — Keychain, Android-ban — EncryptedSharedPreferences, a weben — HttpOnly cookie. Törlés kijelentkezéskor történik: a kliens törli a tokent a tárolóból, a szerver törli a munkamenet rekordját a Redis-ből. Kijelentkezés után a session token haszontalanná válik — a szerver nem találja a megfelelő rekordot.

A SANS Institute, 2025 adatai szerint a munkamenet helyes befejezése (kijelentkezés szerveroldali tisztítással) megakadályozza a lopott tokenekkel végzett támadások akár 70%-át. Kritikus fontosságú, hogy ne csak a kliensnél töröljük a tokent, hanem a szerveren is érvénytelenítsük a munkamenetet.

Session Token vs JWT

Session Token és a JWT két különböző megközelítést képvisel a hitelesítésben. Session Token — stateful (a szerver tárolja az állapotot), JWT — stateless (az adatok a tokenben találhatók). A köztük lévő választás az alkalmazás architektúrájától és a biztonsági követelményektől függ.

Mikor válasszuk a Session Token-t

Session Token akkor előnyös, ha: azonnali munkamenet-visszavonás szükséges (banki, admin felületek), az alkalmazás egy vagy több szerveren fut közös Redis-szel, a munkamenet adatai nagyok és nem férnek el a JWT-ben, vagy ha a csapat minimalizálni akarja az adatok token dekódolással történő kiszivárgásának kockázatát. Ilyen forgatókönyvekben a session token azonnali hozzáférés-blokkolást biztosít gyanús tevékenység esetén — elég egy rekordot törölni a Redis-ből, és a felhasználó összes munkamenete érvénytelenné válik.

A Redis, 2025 adatai szerint a TTL használata a munkamenet-kulcsok szintjén (EXPIRE parancs) automatikusan eltávolítja a lejárt munkameneteket háttérfeladatok többletköltsége nélkül. Az 1 órás TTL-lel és 10 000 egyidejű felhasználó terhelésével rendelkező munkamenetek esetén 1 KB munkamenet-méret mellett a Redis körülbelül 1 GB RAM-ot fogyaszt, ami gazdaságilag hatékonnyá teszi a legtöbb alkalmazás számára.

A Session Token biztonsága

A session token biztonsága két elven alapul: a tokennek kiszámíthatatlannak és védettnek kell lennie az átvitel és tárolás során. A fő fenyegetések — a token elfogása (man-in-the-middle, XSS), kiszámítása (gyenge generálás) és a munkamenet-rögzítés (session fixation).

Védelem a token lopása ellen

Védelem magában foglalja: HTTPS használata minden tokenes kéréshez, rövid munkamenet TTL beállítása (15–60 perc inaktivitás), a munkamenet IP-hez és user-agenthez kötése (további ellenőrzés minden kérésnél), Secure és HttpOnly jelzők használata a cookie-hoz, a session token rendszeres rotálása érzékeny műveletek után (jelszóváltoztatás, jogosultságok emelése). Az OWASP azt is javasolja, hogy valósítsuk meg a Munkamenet-kezelést a régi munkamenet érvénytelenítésével egy új létrehozásakor a bejelentkezés után — ez megakadályozza a munkamenet-rögzítést.

A OWASP ASVS, 2025 adatai szerint a munkamenetet legalább két tényezőhöz kell kötni: magához a tokenhez (ami a kliensnél van) és IP/user-agenthez (amit a szerver ismer). Ha ezek a tényezők nem egyeznek, a szervernek be kell fejeznie a munkamenetet és új hitelesítést kell kérnie.

Megvalósítási példa Kotlinban

Az alábbiakban egy szerveroldali session token megvalósítási példa látható Kotlinban Spring Boot és Redis használatával. A szerver kriptográfiailag biztonságos tokent generál a SecureRandom segítségével, elmenti a munkamenetet a Redis-be TTL-lel, és minden kérésnél ellenőrzi azt. A kód három fő műveletet mutat be: munkamenet létrehozása, érvényesítés és érvénytelenítés.

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

Ez a megvalósítás a JedisPool-t használja a thread-biztos Redis kapcsolathoz. A createSession metódus 1 órás (3600 másodperc) TTL-t állít be — ezen idő letelte után a Redis automatikusan törli a rekordot. A validateSession metódus null-t ad vissza nem létező vagy lejárt munkamenetek esetén, ami lehetővé teszi a szerver számára, hogy helyesen dolgozza fel az érvénytelen token-nel érkező kérést, és HTTP 401-et adjon vissza.