Access Token iOS va Android ilovalarida — asosiy tushunchalar, token turlari va qanday ishlaydi

Access Token nima?

Access Token — bu mijoz (mobil ilova, SPA, server) himoyalangan API endpointlariga HTTP so'rovlarini autentifikatsiya qilish uchun foydalanadigan belgilar qatoridir. Token foydalanuvchi o'z shaxsini tasdiqlab, ilovaga tegishli ruxsatlarni (scope) berganidan so'ng avtorizatsiya serveri tomonidan chiqariladi.

Access token OAuth 2.0 protokoli va uning asosida qurilgan barcha tizimlarning — OpenID Connect, Firebase Authentication, Auth0, Keycloak — markaziy elementidir. Access tokensiz himoyalangan API ga hech qanday so'rov ishlanmaydi: server HTTP 401 Unauthorized qaytaradi. Token foydalanuvchini bevosita identifikatsiya qilmaydi — u mijozning foydalanuvchi nomidan muayyan harakatni bajarish huquqiga ega ekanligini tasdiqlaydi (avtorizatsiya), foydalanuvchi kimligini emas (autentifikatsiya).

Okta, 2025 ma'lumotlariga ko'ra, ommaviy API larning 80% dan ortig'i Authorization sarlavhasida access token bilan Bearer sxemasidan foydalanadi, eskirgan autentifikatsiya usullari — Basic Auth va API Key — ni siqib chiqaradi. Access token shuningdek delegated authorization — foydalanuvchi ilovaga boshqa xizmatdagi ma'lumotlariga cheklangan kirishni beradigan model — uchun asosdir. Masalan, foto tahrirlash uchun mobil ilova OAuth 2.0 orqali Google Drive ga kirishni so'raganda, foydalanuvchi aniq scope lar sanab o'tilgan rozilik ekranini ko'radi va tasdiqlashdan so'ng ushbu huquqlar bilan access token oladi.

Access Token qanday ishlaydi

Access token ishlash mexanizmi Bearer sxemasiga asoslanadi: mijoy har bir HTTP so'roviga Authorization: Bearer <token> sarlavhasini qo'shadi. Resurs serveri (API) tokenni qabul qiladi, uning haqiqiyligini tekshiradi va qaysi resurslar mavjudligini aniqlaydi. Tekshirish ikki usulda amalga oshirilishi mumkin: mahalliy (JWT uchun) yoki introspection endpoint orqali (opaque token uchun).

Bearer Token sxemasi

Bearer token shuni anglatadiki, tokenni taqdim etgan har bir kishi (bearer — taqdim etuvchi) tegishli kirish huquqini oladi. Bu tokenni uzatish va saqlashda himoya qilishga yuqori talablar qo'yadi. Bearer sxemasi mijozdan token egaligini kriptografik isbotlashni talab qilmaydi — uni shunchaki uzatish kifoya. Shuning uchun HTTPS majburiydir: trafikni shifrlamasdan, tajovuzkor tokenni tutib olishi va darhol ishlatishi mumkin.

Cloudflare, 2025 ma'lumotlariga ko'ra, himoyalanmagan HTTP ulanish orqali Bearer tokenni tutib olish so'rov yuborilgandan keyin o'rtacha 12 soniya ichida sodir bo'ladi. HTTPS va qisqa TTL access token (15–30 daqiqa) dan foydalanish xavfni amalda nolga tushiradi. Qo'shimcha dastur darajasidagi himoya — OAuth 2.0 Token Binding (RFC 8471) orqali so'rov kelib chiqishini tekshirish: mijoy token bilan bog'liq TLS kalitiga egaligini isbotlaydi, bu esa tokenni tutib olish orqali o'g'irlashni foydasiz qiladi.

Access Token turlari

Access token ikki formatda mavjud: opaque (shaffof bo'lmagan) va JWT (o'zini-o'zi ta'minlovchi). Ularning o'rtasida tanlov autentifikatsiya tizimini loyihalashdagi asosiy arxitektura qarorlaridan biridir.

Opaque vs JWT

Opaque token kirishni bir zumda bekor qilish va markazlashtirilgan huquq tekshiruvi talab qilinadigan tizimlar uchun afzaldir. JWT — unumdorlik va tarmoq chaqiruvlarini minimallashtirish muhim bo'lgan mikroxizmat arxitekturasi uchun. Ko'plab provayderlar (Auth0, Keycloak) ikkala formatni ham qo'llab-quvvatlaydi va har bir mijoz uchun token turini sozlashga imkon beradi. Opaque va JWT o'rtasidagi tanlov nazorat va unumdorlik o'rtasidagi kelishuvdir: opaque serverga to'liq nazorat beradi, JWT — minimal kechikish.

Access Token hayotiy sikli

Access token hayotiy sikli to'rt fazadan iborat: chiqarish (issuance), uzatish, foydalanish va muddatning tugashi. Har bir faza o'zining xavfsizlik talablari va protokol cheklovlariga ega.

Muddatning tugashi va yangilanishi

Access token cheklangan umrga ega — odatda 15–60 daqiqa. expires_in qiymati token chiqarilganda avtorizatsiya serverining javobida ko'rsatiladi. Bu muddat tugagandan so'ng token haqiqiy emas bo'ladi va mijoy refresh token mexanizmi orqali yangisini olishi kerak. Mijoy muddatning tugashini ikki usulda tekshirishi mumkin: JWT dagi exp maydoni orqali (mahalliy) yoki HTTP 401 javobi orqali (opaque token uchun).

Auth0 Best Practices, 2025 ma'lumotlariga ko'ra, mobil ilovalar uchun optimal TTL 15–30 daqiqadir. Juda qisqa TTL (5 daqiqadan kam) har bir yangilashda token endpoint ga haddan tashqari yuk yaratadi — 10 000 foydalanuvchi va 5 daqiqa TTL bilan server tepa soatlarda daqiqasiga 2 000 ga yaqin yangilash so'rovini oladi. Juda uzun TTL (2 soatdan ko'p) token sizib chiqishida hujum oynasini kengaytiradi — tajovuzkor kirish avtomatik bloklanmaguncha necha soat davomida buzilgan tokendan foydalanishi mumkin.

Access Token xavfsizligi

Access token xavfsizligi barcha bosqichlarda ta'minlanishi kerak: qurilmada saqlashda, tarmoq orqali uzatishda va serverda qayta ishlashda. Asosiy tavsiya — access tokenni boshqa ilovalar yoki jarayonlar uchun ochiq joylarda saqlamang.

Saqlash va uzatishda himoya

Mobil qurilmalarda access token saqlanadi: iOS da — kSecAttrAccessibleAfterFirstUnlock atributi bilan Keychain da (token birinchi qulfdan ochishdan so'ng, hatto qurilma bloklangan bo'lsa ham mavjud — fon yangilanishlari uchun); Android da — EncryptedSharedPreferences da. Access token hech qachon NSUserDefaults, SharedPreferences, tashqi xotiradagi fayllarda yoki ilova loglarida saqlanmasligi kerak. Uzatish vaqtida — faqat TLS 1.3 yoki 1.2 bilan HTTPS. Har bir API so'rovi uchun access token URL parametrlarida (query string) emas, Authorization: Bearer sarlavhasida uzatilishi kerak — URL server va brauzerlar loglariga tushadi.

OWASP Mobile Top 10, 2025 ma'lumotlariga ko'ra, qurilmada tokenlarning noto'g'ri saqlanishi (M1: Improper Platform Usage) va xavfsiz bo'lmagan ma'lumot uzatilishi (M3: Insecure Communication) hisoblarning buzilishiga olib keladigan eng keng tarqalgan uchta mobil zaifliklardandir. Qo'shimcha chora — access token bilan barcha so'rovlar uchun certificate pinning ishlatish: mijoy server sertifikatini nafaqat standart CA zanjiri orqali, balki oldindan saqlangan sertifikat izi (SHA-256 fingerprint) orqali ham tekshiradi. Bu hatto buzilgan CA holatida ham man-in-the-middle hujumlarining oldini oladi.

Kotlin kod namunasi

Quyida Android uchun Kotlin tilida Authorization sarlavhasida access token bilan so'rov yuborish va refresh token orqali avtomatik yangilash bilan 401 ni qayta ishlash namunasi keltirilgan. Maxsus Interceptor bilan OkHttp ishlatiladi.

data class TokenStore {
    fun getAccessToken(): String? {
        // EncryptedSharedPreferences dan o'qish
        return encryptPrefs.getString("access_token", null)
    }

    fun isTokenExpired(): Boolean {
        val expiresAt = encryptPrefs.getLong("expires_at", 0)
        return System.currentTimeMillis() > expiresAt
    }
}

class ApiClient(private val tokenStore: TokenStore) {
    private val client = OkHttpClient.Builder()
        .addInterceptor(AuthInterceptor(tokenStore))
        .build()

    fun fetchUserProfile(): UserProfile? {
        val request = Request.Builder()
            .url("https://api.example.com/user/profile")
            .get()
            .build()

        val response = client.newCall(request).execute()
        return if (response.isSuccessful) {
            parseProfile(response.body?.string() ?: return null)
        } else null
    }
}

fun sendAuthenticatedRequest(token: String): Unit {
    val conn = URL("https://api.example.com/data").openConnection() as HttpURLConnection
    conn.setRequestProperty("Authorization", "Bearer $token")
    conn.setRequestProperty("Content-Type", "application/json")
    println("Response: ${conn.responseCode}")
}

Misolda ikkita yondashuv ko'rsatilgan: avtomatik token boshqaruvi uchun OkHttp Interceptordan foydalanish va HttpURLConnection orqali to'g'ridan-to'g'ri yuborish. OkHttp Interceptor afzal — u tokenni qo'shish va yangilash mantiqini markazlashtiradi va har bir so'rovda kod takrorlanishini bartaraf qiladi. Barcha so'rovlar javob holatini tekshiradigan va kerak bo'lganda dasturchi ishtirokisiz tokenni yangilaydigan yagona interceptor orqali o'tadi.