Ko‘p tizimlarda login jarayonida access token va refresh token ishlatiladi, lekin amaliyotda ularni noto‘g‘ri qo‘llash sababli xavfsizlik zaiflashib ketayotgan holatlar juda ko‘p uchraydi.

Avvalo farqini aniq tushunib olish kerak.

Ko‘pchilik yo‘l qo‘yadigan xatoliklar shu yerdan boshlanadi.

Eng keng tarqalgan xato bu access token va refresh tokenni bir xil muddatga berish yoki ikkalasini ham localStorage’da saqlash. Agar refresh token JavaScript orqali o‘qiladigan joyda saqlansa, bitta XSS hujum butun akkauntni kompromat qiladi.

Yana bir xato refresh tokenni server tomonda nazorat qilmaslik. Ya’ni refresh token ishlatilganda eski token bekor qilinmaydi, aylantirish mexanizmi yo‘q. Natijada token o‘g‘irlangan bo‘lsa ham foydalanuvchi buni sezmaydi.

Best practice qanday bo‘lishi kerak.

Access token qisqa umrli bo‘lishi kerak. Odatda 5-15 daqiqa yetarli. U faqat API chaqirish uchun ishlatiladi va imkon qadar kam vakolatga ega bo‘ladi.

Refresh token esa HttpOnly va Secure cookie orqali saqlanishi kerak. JavaScript uni o‘qiy olmasligi shart. Har bir refresh jarayonida yangi refresh token berilib, eskisi bazada bekor qilinadi. Bu token rotation deb ataladi.

Server tomonda refresh tokenlar albatta saqlanadi va foydalanuvchi, qurilma yoki sessiya bilan bog‘lanadi. Agar bitta refresh token ikki marta ishlatilsa, bu allaqachon signal bo‘lishi kerak va barcha sessiyalar bekor qilinadi.

Himoyani mustahkamlash uchun qo‘shimcha tavsiyalar.

IP yoki device fingerprint bilan refresh tokenni bog‘lash xavfsizlikni oshiradi. Lekin bu juda qat’iy bo‘lsa, foydalanuvchi tajribasiga salbiy ta’sir qilishi mumkin, shuning uchun balans muhim.

Logout bo‘lganda faqat frontend tokenni o‘chirish yetarli emas. Server tomonda refresh token ham invalid qilinishi shart.

Agar imkon bo‘lsa, sensitive endpointlar uchun qo‘shimcha tekshiruvlar masalan re-auth yoki step-up verification ishlatish foydali.

Quyida eng asosiy case-larni ko‘rib chiqamiz:

1. C2M – Client to Machine / User to API
   • Klassik web yoki mobile login.
   • Foydalanuvchi (client) server API-ga access token bilan so‘rov yuboradi.
   • Refresh token esa access token muddati tugagach, yangi access token olish uchun ishlatiladi.
   • Xato: access token uzun muddatli berilishi yoki refresh token localStorage’da saqlanishi.
   • Best practice: short-lived access token + HttpOnly refresh token, rotation qo‘llash.

     Misol: mobil banking app foydalanuvchisi login qiladi, session 10 daqiqa ishlaydi, keyin refresh token orqali yangilanadi.

2. M2M – Machine to Machine / Server to Server
   • Ikkita server yoki mikroservice o‘rtasida o‘zaro API chaqiruvi.
   • Bu yerda foydalanuvchi yo‘q, faqat service identity (client credentials grant) ishlatiladi.
   • Access token server tomonidan olinadi va qisqa muddat ishlatiladi.
   • Refresh token ko‘pincha ishlatilmaydi, chunki server o‘z identifikatori bilan har doim yangi token olishi mumkin.
   • Xato: tokenni static saqlash yoki uzoq muddatli berish.

     Misol: Payment gateway serveri boshqa microservice API-sini chaqiradi.

3. C2C / P2P – Client to Client / User to User
   • Masalan chat app, P2P fayl almashinuvi.
   • Foydalanuvchilar o‘z tokenlarini yuborib, bevosita boshqa foydalanuvchi resurslariga kirishadi.
   • Xavfsizlik nuqtai nazaridan access token qisqa muddatli bo‘lishi va refresh token faqat server orqali yangilanishi muhim.
   • Xato: client o‘zi tokenni boshqalar bilan almashadi yoki saqlaydi.

     Misol: Telegram / WhatsApp session management.

4. Sensitive action + step-up verification
   • Har bir yuqori xavfli action (parol o‘zgartirish, to‘lov, email update) uchun token yetarli emas.Re-auth yoki 2FA talab qilinadi.
   • Risk based approach qo‘llanadi: device, IP, location, harakat pattern.

     Misol: bank app foydalanuvchisi yangi kartani qo‘shadi → server auth_level va risk_score tekshiradi → 2FA talab qiladi.