Session Token ve vývoji aplikací — co to je, princip fungování a rozdíly od JWT

Co je Session Token?

Session Token (identifikátor relace) — je jedinečný řetězec, který server generuje a propojuje s daty relace po ověření uživatele. Token neobsahuje žádné informace o uživateli — je to pouze klíč k datům uloženým na serveru. Tento přístup se nazývá stateful autentizace: server ukládá stav každé aktivní relace a kontroluje jej při každém požadavku.

Data relace zahrnují: identifikátor uživatele, čas přihlášení, IP adresu, user-agent, seznam oprávnění (permissions), čas poslední aktivity. Když klient odešle požadavek se session token, server najde odpovídající záznam v úložišti relací, zkontroluje jeho platnost a získá data pro zpracování požadavku. Pokud záznam relace chybí nebo vypršel, server vrátí chybu autentizace a vyžaduje opětovné přihlášení.

Podle údajů OWASP, 2025 zůstává session token standardem pro aplikace vyžadující okamžité zrušení přístupu — například v bankovních systémech a firemních portálech, kde musí mít správce možnost okamžitě ukončit relaci uživatele. V takových systémech poskytuje session token plnou kontrolu nad přístupem, nedosažitelnou pro stateless tokeny bez dalších mechanismů blokování.

Jak funguje Session Token

Proces fungování začíná tím, že klient odešle přihlašovací údaje na autentizační server. Server zkontroluje uživatelské jméno a heslo, vytvoří záznam relace v úložišti (obvykle Redis nebo databáze) a vrátí klientovi jedinečný session token. Klient token uloží a předává jej s každým následujícím požadavkem, přičemž server pokaždé kontroluje existenci a platnost relace.

Serverová relace a úložiště

Redis — nejoblíbenější úložiště relací díky ukládání do paměti a podpoře TTL (time-to-live). Každá relace je uložena jako pár klíč-hodnota, kde klíč je session token a hodnota je JSON objekt s daty relace. TTL automaticky odstraňuje vypršené relace. Alternativy: Memcached (pouze paměť, bez ukládání na disk), PostgreSQL/MySQL (perzistence, ale pomalejší) a DynamoDB (pro infrastrukturu AWS).

Příklad struktury relace v Redis: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. Server aktualizuje lastAccess při každém požadavku, což umožňuje implementovat časový limit nečinnosti — automatické ukončení relace po období nečinnosti.

Cookie vs Header

Session Token lze přenášet dvěma způsoby: přes HTTP cookie nebo přes HTTP hlavičku Authorization. Cookie — tradiční způsob pro webové aplikace: server nastaví cookie s příznaky HttpOnly (nepřístupný JavaScriptu), Secure (pouze HTTPS) a SameSite (ochrana proti CSRF). Pro mobilní aplikace se častěji používá hlavička Authorization: Bearer <session_token>, protože mechanismus cookie není vždy vhodný v nativních klientech.

Životní cyklus Session Token

Životní cyklus session token zahrnuje tři fáze: vytvoření, udržování aktivní relace a ukončení. Každá fáze vyžaduje správnou konfiguraci zabezpečení, aby se zabránilo úniku nebo zachycení tokenu.

Vytvoření, uložení a odstranění

Vytvoření — server generuje kryptograficky bezpečný náhodný řetězec o délce 128–256 bitů (např. pomocí SecureRandom v Java nebo os.urandom v Python). Token musí být nepředvídatelný — použití UUID nebo časového razítka bez entropie není povoleno. Uložení na klientovi: v iOS — Keychain, v Android — EncryptedSharedPreferences, na webu — HttpOnly cookie. Odstranění nastává při odhlášení: klient odstraní token z úložiště, server odstraní záznam relace z Redis. Po odhlášení se session token stává nepoužitelným — server nenalezne odpovídající záznam.

Podle údajů SANS Institute, 2025 správná implementace ukončení relace (odhlášení s vyčištěním na serveru) zabraňuje až 70% útoků s použitím odcizených tokenů. Je kriticky důležité nejen odstranit token na klientovi, ale také anulovat relaci na serveru.

Session Token vs JWT

Session Token a JWT představují dva různé přístupy k autentizaci. Session Token — stateful (server ukládá stav), JWT — stateless (data uvnitř tokenu). Volba mezi nimi závisí na architektuře aplikace a bezpečnostních požadavcích.

Kdy zvolit Session Token

Session Token je preferován, když: je vyžadováno okamžité zrušení relací (bankovnictví, admin panely), aplikace běží na jednom nebo více serverech se sdíleným Redis, data relace jsou velká a nevejdou se do JWT, nebo když tým chce minimalizovat riziko úniku dat prostřednictvím dekódování tokenu. V takových scénářích poskytuje session token okamžité blokování přístupu při podezřelé aktivitě — stačí odstranit jeden záznam z Redis a všechny relace uživatele se stanou neplatnými.

Podle údajů Redis, 2025 použití TTL na úrovni klíčů relace (příkaz EXPIRE) automaticky čistí vypršené relace bez dodatečných nákladů na úlohy na pozadí. Pro relace s TTL 1 hodina a zátěží 10 000 současných uživatelů při velikosti relace 1 KB spotřebovává Redis přibližně 1 GB RAM, což jej činí ekonomicky efektivním pro většinu aplikací.

Bezpečnost Session Token

Bezpečnost session token je založena na dvou principech: token musí být nepředvídatelný a chráněný při přenosu a ukládání. Hlavní hrozby — zachycení tokenu (man-in-the-middle, XSS), jeho předvídání (slabá generace) a fixace relace (session fixation).

Ochrana proti krádeži tokenu

Ochrana zahrnuje: použití HTTPS pro všechny požadavky s tokenem, nastavení krátkého TTL relace (15–60 minut nečinnosti), vázání relace na IP a user-agent (dodatečná kontrola při každém požadavku), použití Secure a HttpOnly příznaků pro cookie, pravidelnou rotaci session token po citlivých operacích (změna hesla, zvýšení oprávnění). OWASP také doporučuje implementovat Správu relací s invalidací staré relace při vytváření nové po přihlášení — to zabraňuje fixaci relace.

Podle údajů OWASP ASVS, 2025 by relace měla být vázána alespoň na dva faktory: samotný token (co má klient) a IP/user-agent (co je známo serveru). Při neshodě těchto faktorů by měl server ukončit relaci a vyžadovat opětovnou autentizaci.

Příklad implementace v Kotlin

Níže je uveden příklad serverové implementace session token v Kotlin s použitím Spring Boot a Redis. Server generuje kryptograficky bezpečný token přes SecureRandom, ukládá relaci v Redis s TTL a kontroluje ji při každém požadavku. Kód demonstruje tři hlavní operace: vytvoření relace, validaci a invalidaci.

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

Tato implementace používá JedisPool pro bezpečné připojení k Redis ve vícevláknovém prostředí. Metoda createSession nastavuje TTL 1 hodinu (3600 sekund) — po této době Redis automaticky odstraní záznam. Metoda validateSession vrací null pro neexistující nebo vypršené relace, což umožňuje serveru správně zpracovat požadavek s neplatným tokenem a vrátit HTTP 401.