Ilovalarni ishlab chiqishda Session Token — bu nima, ishlash prinsipi va JWT dan farqlari

Session Token nima?

Session Token (sessiya identifikatori) — bu server foydalanuvchi autentifikatsiyasidan so‘ng yaratadigan va sessiya ma’lumotlari bilan bog‘laydigan noyob qatordir. Token foydalanuvchi haqida hech qanday ma’lumotga ega emas — bu faqat serverda saqlanadigan ma’lumotlarning kalitidir. Bunday yondashuv stateful autentifikatsiyasi deb ataladi: server har bir faol sessiyaning holatini saqlaydi va har bir so‘rovda uni tekshiradi.

Sessiya ma’lumotlariga quyidagilar kiradi: foydalanuvchi identifikatori, kirish vaqti, IP manzili, user-agent, ruxsatlar ro‘yxati (permissions), oxirgi faollik vaqti. Mijoz session token bilan so‘rov yuborganda, server sessiyalar omboridan tegishli yozuvni topadi, uning haqiqiyligini tekshiradi va so‘rovni qayta ishlash uchun ma’lumotlarni chiqaradi. Agar sessiya yozuvi mavjud bo‘lmasa yoki muddati o‘tgan bo‘lsa, server autentifikatsiya xatosini qaytaradi va qayta kirishni talab qiladi.

OWASP, 2025 ma’lumotlariga ko‘ra, session token darhol kirishni bekor qilish talab qilinadigan ilovalar uchun standart bo‘lib qolmoqda — masalan, bank tizimlari va korporativ portallarda, administrator foydalanuvchi sessiyasini bir zumda tugatish imkoniyatiga ega bo‘lishi kerak. Bunday tizimlarda session token qo‘shimcha blokirovka mexanizmlarisiz stateless tokenlar uchun erishib bo‘lmaydigan to‘liq kirish nazoratini ta’minlaydi.

Session Token qanday ishlaydi

Ishlash jarayoni mijozning autentifikatsiya serveriga hisob ma’lumotlarini yuborishi bilan boshlanadi. Server login va parolni tekshiradi, omborda (odatda Redis yoki ma’lumotlar bazasi) sessiya yozuvini yaratadi va mijozga noyob session token qaytaradi. Mijoz tokenni saqlaydi va uni har bir keyingi so‘rov bilan birga yuboradi, server esa har safar sessiyaning mavjudligi va haqiqiyligini tekshiradi.

Server sessiyasi va ombor

Redis — xotirada saqlash va TTL (time-to-live) qo‘llab-quvvatlashi tufayli eng mashhur sessiyalar ombori. Har bir sessiya kalit-qiymat juftligi sifatida saqlanadi, bunda kalit session token, qiymat esa sessiya ma’lumotlari bilan JSON obyektidir. TTL muddati o‘tgan sessiyalarni avtomatik ravishda o‘chiradi. Alternativlar: Memcached (faqat xotira, diskka saqlashsiz), PostgreSQL/MySQL (bardoshlik, lekin sekinroq) va DynamoDB (AWS infratuzilmasi uchun).

Redis da sessiya tuzilishi namunasi: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. Server har bir so‘rovda lastAccess ni yangilaydi, bu harakatsizlik vaqti limitini amalga oshirishga imkon beradi — harakatsizlik davridan so‘ng sessiyaning avtomatik tugatilishi.

Cookie vs Header

Session Token ikki usulda uzatilishi mumkin: HTTP cookie orqali yoki HTTP Authorization sarlavhasi orqali. Cookie — veb-ilovalar uchun an’anaviy usul: server HttpOnly (JavaScript uchun mavjud emas), Secure (faqat HTTPS) va SameSite (CSRF dan himoya) bayroqlari bilan cookie o‘rnatadi. Mobil ilovalar uchun ko‘pincha Authorization: Bearer <session_token> sarlavhasi ishlatiladi, chunki cookie mexanizmi mahalliy mijozlarda har doim ham qulay emas.

Session Token hayot aylanishi

Hayot aylanishi session token uch bosqichni o‘z ichiga oladi: yaratish, faol sessiyani saqlash va tugatish. Har bir bosqich tokenning sizib chiqishi yoki tutib olinishining oldini olish uchun to‘g‘ri xavfsizlik sozlamalarini talab qiladi.

Yaratish, saqlash va o'chirish

Yaratish — server 128–256 bit uzunlikdagi kriptografik xavfsiz tasodifiy qatorni yaratadi (masalan, Java da SecureRandom yoki Python da os.urandom orqali). Token oldindan aytib bo‘lmaydigan bo‘lishi kerak — entropiyasiz UUID yoki vaqt tamg‘asidan foydalanishga yo‘l qo‘yilmaydi. Saqlash mijozda: iOS da — Keychain, Android da — EncryptedSharedPreferences, vebda — HttpOnly cookie. O‘chirish chiqish vaqtida sodir bo‘ladi: mijoz tokenni ombordan o‘chiradi, server Redis dan sessiya yozuvini o‘chiradi. Chiqishdan so‘ng session token yaroqsiz bo‘ladi — server tegishli yozuvni topmaydi.

SANS Institute, 2025 ma’lumotlariga ko‘ra, sessiyani to‘g‘ri tugatish (serverda tozalash bilan chiqish) o‘g‘irlangan tokenlardan foydalanadigan hujumlarning 70% gacha oldini oladi. Faqat mijozda tokenni o‘chirish emas, balki serverda sessiyani bekor qilish ham juda muhimdir.

Session Token vs JWT

Session Token va JWT autentifikatsiyaga ikki xil yondashuvni ifodalaydi. Session Token — stateful (server holatni saqlaydi), JWT — stateless (ma’lumotlar token ichida). Ularning orasidagi tanlov ilova arxitekturasi va xavfsizlik talablariga bog‘liq.

Qachon Session Token ni tanlash kerak

Session Token quyidagi hollarda afzal: sessiyalarni darhol bekor qilish talab qilinganda (bank ishi, boshqaruv panellari), ilova umumiy Redis bilan bir yoki bir nechta serverda ishlaganda, sessiya ma’lumotlari katta bo‘lib JWT ga sig‘maganda, yoki jamoa tokenni dekodlash orqali ma’lumot sizib chiqishi xavfini minimallashtirishni xohlaganda. Bunday stsenariylarda session token shubhali faollikda darhol kirishni blokirovka qilishni ta’minlaydi — Redis dan bitta yozuvni o‘chirish kifoya va foydalanuvchining barcha sessiyalari yaroqsiz bo‘ladi.

Redis, 2025 ma’lumotlariga ko‘ra, sessiya kalitlari darajasida TTL (EXPIRE buyrug‘i) dan foydalanish fon vazifalariga qo‘shimcha xarajatlarsiz muddati o‘tgan sessiyalarni avtomatik tozalaydi. TTL 1 soat va 10 000 bir vaqtli foydalanuvchi yuklamasi bilan sessiya hajmi 1 KB bo‘lganda Redis taxminan 1 GB RAM iste’mol qiladi, bu uni ko‘pgina ilovalar uchun iqtisodiy jihatdan samarali qiladi.

Session Token xavfsizligi

Xavfsizlik session token ikki tamoyilga asoslanadi: token oldindan aytib bo‘lmaydigan va uzatish hamda saqlash paytida himoyalangan bo‘lishi kerak. Asosiy tahdidlar — tokenning tutib olinishi (man-in-the-middle, XSS), uning oldindan aytilishi (zaif yaratish) va sessiya fiksatsiyasi (session fixation).

Token o'g'irlanishidan himoya

Himoya quyidagilarni o‘z ichiga oladi: token bilan barcha so‘rovlarda HTTPS dan foydalanish, qisqa sessiya TTL ni o‘rnatish (15–60 daqiqa harakatsizlik), sessiyani IP va user-agent bilan bog‘lash (har bir so‘rovda qo‘shimcha tekshirish), cookie uchun Secure va HttpOnly bayroqlaridan foydalanish, sezuvchan operatsiyalardan so‘ng session token ni muntazam aylantirish (parolni o‘zgartirish, huquqlarni oshirish). OWASP shuningdek, kirishdan so‘ng yangi sessiya yaratishda eski sessiyani bekor qilish bilan Sessiyalarni boshqarish ni amalga oshirishni tavsiya qiladi — bu sessiya fiksatsiyasini oldini oladi.

OWASP ASVS, 2025 ma’lumotlariga ko‘ra, sessiya kamida ikki omilga bog‘langan bo‘lishi kerak: tokenning o‘zi (mijozda mavjud) va IP/user-agent (serverga ma’lum). Ushbu omillar mos kelmasa, server sessiyani tugatishi va qayta autentifikatsiyani talab qilishi kerak.

Kotlin da amalga oshirish misoli

Quyida Spring Boot va Redis yordamida Kotlin da session token ning server amalga oshirish namunasi keltirilgan. Server SecureRandom orqali kriptografik xavfsiz tokenni yaratadi, sessiyani TTL bilan Redis da saqlaydi va har bir so‘rovda uni tekshiradi. Kod uchta asosiy operatsiyani namoyish etadi: sessiyani yaratish, tekshirish va bekor qilish.

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

Ushbu amalga oshirish Redis ga thread-xavfsiz ulanish uchun JedisPool dan foydalanadi. createSession metodi TTL ni 1 soat (3600 soniya) qilib o‘rnatadi — bu muddatdan so‘ng Redis avtomatik ravishda yozuvni o‘chiradi. validateSession metodi mavjud bo‘lmagan yoki muddati o‘tgan sessiyalar uchun null qaytaradi, bu serverga yaroqsiz token bilan so‘rovni to‘g‘ri qayta ishlash va HTTP 401 qaytarish imkonini beradi.