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 или временске ознаке без ентропије није дозвољена. Чување на клијенту: у iOS — Keychain, у Android — EncryptedSharedPreferences, на вебу — HttpOnly cookie. Брисање се дешава при одјави: клијент брише токен из складишта, сервер брише запис сесије из Redis. Након одјаве, session token постаје бескористан — сервер неће пронаћи одговарајући запис.

Према подацима SANS Institute, 2025, правилна имплементација завршавања сесије (одјава са чишћењем на серверу) спрјечава до 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 RAM-а при величини сесије од 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 такође препоручује имплементацију Управљања сесијама са инвалидацијом старе сесије при креирању нове након пријаве — ово спрјечава фиксацију сесије.

Према подацима 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.