Session Token w tworzeniu aplikacji — co to jest, zasada działania i różnice od JWT

Co to jest Session Token?

Session Token (identyfikator sesji) — to unikalny ciąg znaków, który serwer generuje i wiąże z danymi sesji po autoryzacji użytkownika. Token nie zawiera żadnych informacji o użytkowniku — to tylko klucz do danych przechowywanych na serwerze. Takie podejście nazywa się autoryzacją stateful: serwer przechowuje stan każdej aktywnej sesji i sprawdza go przy każdym żądaniu.

Dane sesji obejmują: identyfikator użytkownika, czas logowania, adres IP, user-agent, listę uprawnień (permissions), czas ostatniej aktywności. Gdy klient wysyła żądanie z session token, serwer znajduje odpowiedni rekord w magazynie sesji, sprawdza jego ważność i pobiera dane do przetworzenia żądania. Jeśli rekord sesji nie istnieje lub wygasł, serwer zwraca błąd autoryzacji i wymaga ponownego logowania.

Według danych OWASP, 2025, session token pozostaje standardem dla aplikacji wymagających natychmiastowego unieważnienia dostępu — na przykład w systemach bankowych i portalach korporacyjnych, gdzie administrator musi mieć możliwość natychmiastowego zakończenia sesji użytkownika. W takich systemach session token zapewnia pełną kontrolę nad dostępem, nieosiągalną dla tokenów stateless bez dodatkowych mechanizmów blokowania.

Jak działa Session Token

Proces działania rozpoczyna się od wysłania przez klienta danych uwierzytelniających na serwer autoryzacji. Serwer sprawdza login i hasło, tworzy rekord sesji w magazynie (zwykle Redis lub baza danych) i zwraca klientowi unikalny session token. Klient zapisuje token i przesyła go z każdym kolejnym żądaniem, a serwer za każdym razem sprawdza istnienie i ważność sesji.

Sesja serwerowa i magazyn

Redis — najpopularniejszy magazyn sesji dzięki przechowywaniu w pamięci i wsparciu TTL (time-to-live). Każda sesja jest przechowywana jako klucz-wartość, gdzie klucz to session token, a wartość to obiekt JSON z danymi sesji. TTL automatycznie usuwa wygasłe sesje. Alternatywy: Memcached (tylko pamięć, bez zapisu na dysk), PostgreSQL/MySQL (trwałość, ale wolniejsze) i DynamoDB (dla infrastruktury AWS).

Przykład struktury sesji w Redis: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. Serwer aktualizuje lastAccess przy każdym żądaniu, co umożliwia zaimplementowanie limitu czasu bezczynności — automatyczne zakończenie sesji po okresie braku aktywności.

Cookie vs Header

Session Token może być przesyłany na dwa sposoby: przez HTTP cookie lub przez nagłówek HTTP Authorization. Cookie — tradycyjny sposób dla aplikacji internetowych: serwer ustawia cookie z flagami HttpOnly (niedostępna dla JavaScript), Secure (tylko HTTPS) i SameSite (ochrona przed CSRF). Dla aplikacji mobilnych częściej używany jest nagłówek Authorization: Bearer <session_token>, ponieważ mechanizm cookie nie zawsze jest wygodny w klientach natywnych.

Cykl życia Session Token

Cykl życia session token obejmuje trzy etapy: utworzenie, utrzymywanie aktywnej sesji i zakończenie. Każdy etap wymaga prawidłowej konfiguracji zabezpieczeń, aby zapobiec wyciekowi lub przechwyceniu tokena.

Tworzenie, przechowywanie i usuwanie

Tworzenie — serwer generuje kryptograficznie bezpieczny losowy ciąg znaków o długości 128–256 bitów (np. przez SecureRandom w Java lub os.urandom w Python). Token musi być nieprzewidywalny — użycie UUID lub sygnatury czasowej bez entropii jest niedozwolone. Przechowywanie na kliencie: w iOS — Keychain, w Android — EncryptedSharedPreferences, w sieci — HttpOnly cookie. Usunięcie następuje przy wylogowaniu: klient usuwa token z magazynu, serwer usuwa rekord sesji z Redis. Po wylogowaniu session token staje się bezużyteczny — serwer nie znajdzie odpowiedniego rekordu.

Według danych SANS Institute, 2025, prawidłowa implementacja zakończenia sesji (wylogowanie z czyszczeniem na serwerze) zapobiega do 70% ataków z wykorzystaniem skradzionych tokenów. Krytycznie ważne jest nie tylko usunięcie tokena na kliencie, ale także anulowanie sesji na serwerze.

Session Token vs JWT

Session Token i JWT reprezentują dwa różne podejścia do autoryzacji. Session Token — stateful (serwer przechowuje stan), JWT — stateless (dane wewnątrz tokena). Wybór między nimi zależy od architektury aplikacji i wymagań bezpieczeństwa.

Kiedy wybrać Session Token

Session Token jest preferowany, gdy: wymagane jest natychmiastowe unieważnienie sesji (bankowość, panele administracyjne), aplikacja działa na jednym lub kilku serwerach ze wspólnym Redis, dane sesji są duże i nie mieszczą się w JWT, lub gdy zespół chce zminimalizować ryzyko wycieku danych przez dekodowanie tokena. W takich scenariuszach session token zapewnia natychmiastową blokadę dostępu przy podejrzanej aktywności — wystarczy usunąć jeden rekord z Redis, a wszystkie sesje użytkownika stają się nieważne.

Według danych Redis, 2025, użycie TTL na poziomie kluczy sesji (polecenie EXPIRE) automatycznie czyści wygasłe sesje bez dodatkowych kosztów zadań w tle. Dla sesji z TTL 1 godzina i obciążeniem 10 000 jednoczesnych użytkowników Redis zużywa około 1 GB pamięci RAM przy rozmiarze sesji 1 KB, co czyni go ekonomicznie wydajnym dla większości aplikacji.

Bezpieczeństwo Session Token

Bezpieczeństwo session token opiera się na dwóch zasadach: token musi być nieprzewidywalny i chroniony podczas przesyłania i przechowywania. Główne zagrożenia — przechwycenie tokena (man-in-the-middle, XSS), jego przewidzenie (słabe generowanie) i fiksacja sesji (session fixation).

Ochrona przed kradzieżą tokena

Ochrona obejmuje: używanie HTTPS dla wszystkich żądań z tokenem, ustawienie krótkiego TTL sesji (15–60 minut bezczynności), powiązanie sesji z IP i user-agent (dodatkowe sprawdzenie przy każdym żądaniu), używanie flag Secure i HttpOnly dla cookie, regularną rotację session token po wrażliwych operacjach (zmiana hasła, podniesienie uprawnień). OWASP zaleca również zaimplementowanie Zarządzania sesjami z unieważnieniem starej sesji przy tworzeniu nowej po zalogowaniu — zapobiega to fiksacji sesji.

Według danych OWASP ASVS, 2025, sesja powinna być powiązana co najmniej z dwoma czynnikami: sam token (co ma klient) i IP/user-agent (co jest znane serwerowi). W przypadku niezgodności tych czynników serwer powinien zakończyć sesję i wymagać ponownej autoryzacji.

Przykład implementacji w Kotlin

Poniżej znajduje się przykład serwerowej implementacji session token w Kotlin z użyciem Spring Boot i Redis. Serwer generuje kryptograficznie bezpieczny token przez SecureRandom, zapisuje sesję w Redis z TTL i sprawdza ją przy każdym żądaniu. Kod demonstruje trzy główne operacje: tworzenie sesji, walidację i unieważnienie.

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

Ta implementacja używa JedisPool do bezpiecznego wątkowo połączenia z Redis. Metoda createSession ustawia TTL 1 godzina (3600 sekund) — po tym czasie Redis automatycznie usunie rekord. Metoda validateSession zwraca null dla nieistniejących lub wygasłych sesji, co pozwala serwerowi poprawnie obsłużyć żądanie z nieprawidłowym tokenem i zwrócić HTTP 401.