Tətbiq inkişafında Session Token — bu nədir, işləmə prinsipi və JWT-dən fərqləri

Session Token nədir?

Session Token (sessiya identifikatoru) — bu, serverin istifadəçinin autentifikasiyasından sonra yaratdığı və sessiya məlumatları ilə əlaqələndirdiyi unikal sətirdir. Token istifadəçi haqqında heç bir məlumat daşımır — bu, sadəcə serverdə saxlanılan məlumatların açarıdır. Belə yanaşma stateful autentifikasiyası adlanır: server hər aktiv sessiyanın vəziyyətini saxlayır və hər sorğuda onu yoxlayır.

Sessiya məlumatlarına daxildir: istifadəçi identifikatoru, giriş vaxtı, IP ünvanı, user-agent, icazələr siyahısı (permissions), son aktivlik vaxtı. Müştəri session token ilə sorğu göndərdikdə, server sessiya anbarında müvafiq qeydi tapır, onun etibarlılığını yoxlayır və sorğun işlənməsi üçün məlumatları çıxarır. Sessiya qeydi yoxdursa və ya müddəti keçibsə, server autentifikasiya xətası qaytarır və yenidən daxil olmağı tələb edir.

OWASP, 2025 məlumatlarına görə, session token dərhal girişi ləğv etmək tələb olunan tətbiqlər üçün standart olaraq qalır — məsələn, bank sistemləri və korporativ portallarda, administrator istifadəçinin sessiyasını dərhal sonlandıra bilməlidir. Belə sistemlərdə session token əlavə bloklama mexanizmləri olmadan stateless tokenlər üçün mümkün olmayan tam giriş nəzarətini təmin edir.

Session Token necə işləyir

İşləmə prosesi müştərinin autentifikasiya serverinə giriş məlumatlarını göndərməsi ilə başlayır. Server login və şifrəni yoxlayır, anbarda (adətən Redis və ya verilənlər bazasında) sessiya qeydi yaradır və müştəriyə unikal session token qaytarır. Müştəri tokeni saxlayır və hər növbəti sorğu ilə birlikdə göndərir, server isə hər dəfə sessiyanın mövcudluğunu və etibarlılığını yoxlayır.

Server sessiyası və anbar

Redis — yaddaş daxili saxlanma və TTL (time-to-live) dəstəyi sayəsində ən məşhur sessiya anbarıdır. Hər sessiya açar-dəyər cütlüyü kimi saxlanılır, burada açar session token, dəyər isə sessiya məlumatları olan JSON obyektidir. TTL müddəti keçmiş sessiyaları avtomatik silir. Alternativlər: Memcached (yalnız yaddaş, disksiz), PostgreSQL/MySQL (davamlılıq, lakin yavaş) və DynamoDB (AWS infrastrukturu üçün).

Redis-də sessiya quruluşu nümunəsi: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. Server hər sorğuda lastAccess-i yeniləyir ki, bu da hərəkətsizlik vaxtı limitini tətbiq etməyə imkan verir — hərəkətsizlik dövründən sonra sessiyanın avtomatik bağlanması.

Cookie vs Header

Session Token iki üsulla ötürülə bilər: HTTP cookie vasitəsilə və ya HTTP Authorization başlığı ilə. Cookie — veb-tətbiqlər üçün ənənəvi üsul: server HttpOnly (JavaScript üçün əlçatmaz), Secure (yalnız HTTPS) və SameSite (CSRF-dən qorunma) bayraqları ilə cookie təyin edir. Mobil tətbiqlər üçün daha çox Authorization: Bearer <session_token> başlığı istifadə olunur, çünki cookie mexanizmi native kliyentlərdə həmişə rahat deyil.

Session Token həyat dövrü

Həyat dövrü session token üç mərhələdən ibarətdir: yaradılma, aktiv sessiyanın saxlanması və başa çatma. Hər mərhələ tokenin sızmasını və ya ələ keçirilməsinin qarşısını almaq üçün düzgün təhlükəsizlik konfiqurasiyası tələb edir.

Yaradılma, saxlanma və silinmə

Yaradılma — server 128–256 bit uzunluğunda kriptoqrafik təsadüfi sətir yaradır (məsələn, Java-da SecureRandom və ya Python-da os.urandom vasitəsilə). Token proqnozlaşdırıla bilməz olmalıdır — entropiyasız UUID və ya vaxt damğası istifadəsi yolverilməzdir. Saxlanma kliyentdə: iOS-da — Keychain, Android-də — EncryptedSharedPreferences, vebdə — HttpOnly cookie. Silinmə çıxış zamanı baş verir: kliyent tokeni anbardan silir, server Redis-dən sessiya qeydini silir. Çıxışdan sonra session token yararsız olur — server müvafiq qeydi tapmayacaq.

SANS Institute, 2025 məlumatlarına görə, sessiyanın düzgün başa çatdırılması (serverdə təmizləmə ilə çıxış) oğurlanmış tokenlərdən istifadə edən hücumların 70%-ə qədərinin qarşısını alır. Təkcə kliyentdə tokeni silmək deyil, həm də serverdə sessiyanı ləğv etmək kritik əhəmiyyət daşıyır.

Session Token vs JWT

Session Token və JWT autentifikasiyaya iki fərqli yanaşmanı təmsil edir. Session Token — stateful (server vəziyyəti saxlayır), JWT — stateless (məlumatlar token daxilində). Onlar arasında seçim tətbiqin arxitekturasından və təhlükəsizlik tələblərindən asılıdır.

Session Token nə vaxt seçilməli

Session Token aşağıdakı hallarda üstünlük təşkil edir: sessiyaların dərhal ləğvi tələb olunduqda (bankınq, idarəetmə panelləri), tətbiq ortaq Redis ilə bir və ya bir neçə serverdə işləyirsə, sessiya məlumatları böyükdür və JWT-yə sığmırsa, və ya komanda tokenin dekolajı ilə məlumat sızması riskini minimuma endirmək istəyirsə. Belə ssenarilərdə session token şübhəli aktivlik zamanı dərhal giriş blokadasını təmin edir — Redis-dən bir qeydi silmək kifayətdir və istifadəçinin bütün sessiyaları etibarsız olur.

Redis, 2025 məlumatlarına görə, sessiya açarları səviyyəsində TTL (EXPIRE əmri) istifadəsi fon tapşırıqlarına əlavə xərc çəkmədən müddəti keçmiş sessiyaları avtomatik təmizləyir. TTL 1 saat və 10 000 eyni vaxtlı istifadəçi yükü olan sessiyalar üçün Redis sessiya ölçüsü 1 KB olduqda təxminən 1 GB RAM istehlak edir ki, bu da onu əksər tətbiqlər üçün iqtisadi cəhətdən səmərəli edir.

Session Token təhlükəsizliyi

Təhlükəsizlik session token iki prinsipə əsaslanır: token proqnozlaşdırıla bilməz və ötürülmə və saxlanma zamanı qorunmalıdır. Əsas təhdidlər — tokenin ələ keçirilməsi (man-in-the-middle, XSS), onun proqnozlaşdırılması (zəif generasiya) və sessiya fiksasiyası (session fixation).

Token oğurluğundan qorunma

Qorunma daxildir: token ilə bütün sorğularda HTTPS istifadəsi, qısa sessiya TTL-nin təyin edilməsi (15–60 dəqiqə hərəkətsizlik), sessiyanın IP və user-agent ilə əlaqələndirilməsi (hər sorğuda əlavə yoxlama), cookie üçün Secure və HttpOnly bayraqlarının istifadəsi, həssas əməliyyatlardan sonra session tokenin mütəzəmil rotasiyası (şifrənin dəyişdirilməsi, səlahiyyətlərin artırılması). OWASP həmçinin girişdən sonra yeni sessiya yaradılarkən köhnə sessiyanın ləğvi ilə Sessiya idarəetməsi tətbiqini tövsiyə edir — bu sessiya fiksasiyasının qarşısını alır.

OWASP ASVS, 2025 məlumatlarına görə, sessiya ən azı iki faktora bağlanmalıdır: token özü (kliyentdə olan) və IP/user-agent (serverə məlum olan). Bu amillər uyğun gəlmədikdə, server sessiyanı başa çatdırmalı və yenidən autentifikasiya tələb etməlidir.

Kotlin-də tətbiq nümunəsi

Aşağıda Spring Boot və Redis istifadə edərək Kotlin-də session tokenin server tətbiqi nümunəsi verilmişdir. Server SecureRandom vasitəsilə kriptoqrafik təhlükəsiz token yaradır, sessiyanı TTL ilə Redis-də saxlayır və hər sorğuda onu yoxlayır. Kod üç əsas əməliyyatı nümayiş etdirir: sessiyanın yaradılması, yoxlanması və ləğvi.

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

Bu tətbiq Redis-ə thread-təhlükəsiz qoşulma üçün JedisPool istifadə edir. createSession metodu 1 saat (3600 saniyə) TTL təyin edir — bu müddətdən sonra Redis avtomatik olaraq qeydi siləcək. validateSession metodu mövcud olmayan və ya müddəti keçmiş sessiyalar üçün null qaytarır ki, bu da serverə etibarsız token ilə sorğu düzgün emal etməyə və HTTP 401 qaytarmağa imkan verir.