Session Token у розробці додатків — що це таке, принцип роботи та відмінності від JWT

Що таке Session Token?

Session Token (ідентифікатор сесії) — це унікальний рядок, який сервер генерує та пов'язує з даними сесії після автентифікації користувача. Токен не містить жодної інформації про користувача — це просто ключ до даних, що зберігаються на сервері. Такий підхід називається stateful автентифікацією: сербер зберігає стан кожної активної сесії та перевіряє його при кожному запиті.

Дані сесії включають: ідентифікатор користувача, час входу, IP-адресу, user-agent, список дозволів (permissions), час останньої активності. Коли клієнт надсилає запит із session token, сервер знаходить відповідний запис у сховищі сесій, перевіряє його дійсність та отримує дані для обробки запиту. Якщо запис сесії відсутній або закінчився, сервер повертає помилку автентифікації та вимагає повторного входу.

За даними OWASP, 2025, session token залишається стандартом для додатків, де потрібне негайне відкликання доступу — наприклад, у банківських системах та корпоративних порталах, де адміністратор повинен мати можливість завершити сесію користувача миттєво. У таких системах session token забезпечує повний контроль над доступом, недосяжний для stateless-токенів без додаткових механізмів блокування.

Як працює Session Token

Процес роботи починається з того, що клієнт надсилає облікові дані на сервер автентифікації. Сервер перевіряє логін та пароль, створює запис сесії у сховищі (зазвичай Redis або база даних) та повертає клієнту унікальний session token. Клієнт зберігає токен та передає його з кожним наступним запитом, а сервер щоразу перевіряє існування та дійсність сесії.

Серверна сесія та сховище

Redis — найпопулярніше сховище сесій завдяки in-memory зберіганню та підтримці TTL (time-to-live). Кожна сесія зберігається як ключ-значення, де ключ — session token, а значення — JSON-об'єкт з даними сесії. TTL автоматично видаляє прострочені сесії. Альтернативи: Memcached (тільки пам'ять, без збереження на диск), PostgreSQL/MySQL (персистентність, але повільніше) та DynamoDB (для AWS-інфраструктури).

Приклад структури сесії в Redis: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. Сервер оновлює lastAccess при кожному запиті, що дозволяє реалізувати таймаут неактивності — автоматичне завершення сесії після періоду бездіяльності.

Cookie vs Header

Session Token може передаватися двома способами: через HTTP cookie або через HTTP-заголовок Authorization. Cookie — традиційний спосіб для веб-додатків: сервер встановлює cookie з прапорами HttpOnly (недоступна JavaScript), Secure (тільки HTTPS) та SameSite (захист від CSRF). Для мобільних додатків частіше використовується заголовок Authorization: Bearer <session_token>, оскільки cookie-механізм не завжди зручний у нативних клієнтах.

Життєвий цикл Session Token

Життєвий цикл session token включає три етапи: створення, підтримання активної сесії та завершення. Кожен етап вимагає правильного налаштування безпеки для запобігання витоку або перехоплення токена.

Створення, зберігання та видалення

Створення — сервер генерує криптостійкий випадковий рядок довжиною 128–256 біт (наприклад, через SecureRandom в Java або os.urandom в Python). Токен має бути непередбачуваним — використання UUID або timestamp без ентропії неприпустимо. Зберігання на клієнті: в iOS — Keychain, в Android — EncryptedSharedPreferences, у вебі — HttpOnly cookie. Видалення відбувається при logout: клієнт видаляє токен зі сховища, сервер видаляє запис сесії з Redis. Після logout session token стає марним — сервер не знайде відповідного запису.

За даними SANS Institute, 2025, правильна реалізація завершення сесії (logout з очищенням на сервері) запобігає до 70% атак з використанням викрадених токенів. Критично важливо не просто видаляти токен на клієнті, а й анулювати сесію на сервері.

Session Token vs JWT

Session Token і JWT представляють два різних підходи до автентифікації. Session Token — stateful (сервер зберігає стан), JWT — stateless (дані всередині токена). Вибір між ними залежить від архітектури додатка та вимог до безпеки.

Коли вибрати Session Token

Session Token є кращим, коли: потрібне миттєве відкликання сесій (банкінг, адмін-панелі), додаток працює на одному або кількох серверах зі спільним Redis, дані сесії великі та не поміщаються в JWT, або коли команда хоче мінімізувати ризик витоку даних через декодування токена. У таких сценаріях session token забезпечує негайне блокування доступу при підозрілій активності — достатньо видалити один запис з Redis, і всі сесії користувача стають недійсними.

За даними Redis, 2025, використання TTL на рівні ключів сесії (команда EXPIRE) автоматично очищає прострочені сесії без накладних витрат на фонові завдання. Для сесій з TTL 1 година та навантаженням 10 000 одночасних користувачів Redis споживає близько 1 GB оперативної пам'яті при розмірі сесії 1 KB, що робить його економічно ефективним для більшості додатків.

Безпека Session Token

Безпека session token заснована на двох принципах: токен має бути непередбачуваним та захищеним при передачі та зберіганні. Основні загрози — перехоплення токена (man-in-the-middle, XSS), його передбачення (слабка генерація) та фіксація сесії (session fixation).

Захист від крадіжки токена

Захист включає: використання HTTPS для всіх запитів з токеном, встановлення короткого TTL сесії (15–60 хвилин неактивності), прив'язку сесії до IP та user-agent (додаткова перевірка при кожному запиті), використання Secure та HttpOnly прапорів для cookie, регулярну ротацію session token після чутливих операцій (зміна пароля, підвищення прав). OWASP рекомендує також реалізувати Session Management з інвалідацією старої сесії при створенні нової після логіна — це запобігає session fixation.

За даними OWASP ASVS, 2025, сесія має бути прив'язана мінімум до двох факторів: сам токен (що є у клієнта) та IP/user-agent (що відомо серверу). При неспівпадінні цих факторів сервер має завершити сесію та вимагати повторну автентифікацію.

Приклад реалізації на Kotlin

Нижче наведено приклад серверної реалізації session token на Kotlin з використанням Spring Boot та Redis. Сервер генерує криптостійкий токен через SecureRandom, зберігає сесію в Redis з TTL та перевіряє її при кожному запиті. Код демонструє три основні операції: створення сесії, валідацію та інвалідацію.

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

Дана реалізація використовує JedisPool для потокобезпечного підключення до Redis. Метод createSession встановлює TTL 1 година (3600 секунд) — після цього терміну Redis автоматично видалить запис. Метод validateSession повертає null для неіснуючих або прострочених сесій, що дозволяє серверу коректно обробити запит з недійсним токеном та повернути HTTP 401.