Access Token iOS və Android tətbiqetmələrində — əsas anlayışlar, token növləri və necə işləyir

Access Token nədir?

Access Token — müştərinin (mobil tətbiqetmə, SPA, server) qorunan API endpointlərinə HTTP sorğularının autentifikasiyası üçün istifadə etdiyi simvol sətrir. Token istifadəçi şəxsiyyətini təsdiqlədikdən və tətbiqetməyə müvafiq icazələr (scope) verdikdən sonra avtorizasiya serveri tərəfindən verilir.

Access token OAuth 2.0 protokolunun və onun əsasında qurulmuş bütün sistemlərin — OpenID Connect, Firebase Authentication, Auth0, Keycloak — mərkəzi elementidir. Access token olmadan qorunan API-ə heç bir sorğu işlənməyəcək: server HTTP 401 Unauthorized qaytarır. Token istifadəçini birbaşa identifikasiya etmir — o, müştərinin istifadəçi adından konkret hərəkəti yerinə yetirmək hüququnun olduğunu təsdiqləyir (avtorizasiya), istifadəçinin kim olduğunu deyil (autentifikasiya).

Okta, 2025 məlumatlarına görə, ictimai API-lərin 80%-dən çoxu Authorization başlığında access token ilə Bearer sxemindən istifadə edir və köhnəlmiş autentifikasiya metodlarını — Basic Auth və API Key — sıxışdırır. Access token həmçinin delegated authorization — istifadəçinin tətbiqetməyə digər xidmətdə öz məlumatlarına məhdud giriş verdiyi model — üçün əsasdır. Məsələn, foto redaktəsi üçün mobil tətbiqetmə OAuth 2.0 vasitəsilə Google Drive-a giriş tələb etdikdə, istifadəçi konkret scope-ların sadalandığı razılıq ekranını görür və təsdiqlədikdən sonra bu hüquqlarla access token alır.

Access Token necə işləyir

Access token-in iş mexanizmi Bearer sxeminə əsaslanır: müştəri hər HTTP sorğusuna Authorization: Bearer <token> başlığını əlavə edir. Resurs serveri (API) tokeni alır, onun etibarlılığını yoxlayır və hansı resursların əlçatan olduğunu müəyyən edir. Yoxlama iki şəkildə aparıla bilər: lokal (JWT üçün) və ya introspection endpoint vasitəsilə (opaque token üçün).

Bearer Token sxemi

Bearer token o deməkdir ki, tokeni təqdim edən hər kəs (bearer — təqdim edən) müvafiq giriş əldə edir. Bu, tokenin ötürülməsi və saxlanması zamanı qorunmasına yüksək tələblər qoyur. Bearer sxemi müştəridən tokenə sahibliyi kriptoqrafik olaraq sübut etməyi tələb etmir — sadəcə onu ötürmək kifayətdir. Buna görə HTTPS məcburidir: trafikin şifrələnməsi olmadan təcavüzkar tokeni ələ keçirə və dərhal istifadə edə bilər.

Cloudflare, 2025 məlumatlarına görə, Bearer token-in qorunmayan HTTP bağlantısı vasitəsilə ələ keçirilməsi sorğu göndərildikdən sonra orta hesabla 12 saniyə ərzində baş verir. HTTPS və qısa TTL access token (15–30 dəqiqə) istifadəsi riski praktiki olaraq sıfıra endirir. Əlavə tətbiq səviyyəsində qorunma — OAuth 2.0 Token Binding (RFC 8471) vasitəsilə sorğunun mənşəyinin yoxlanılması: müştəri tokenlə əlaqəli TLS açarına sahib olduğunu sübut edir ki, bu da tokenin ələ keçirmə yolu ilə oğurlanmasını faydasız edir.

Access Token növləri

Access token iki formatda mövcuddur: opaque (qeyri-şəffaf) və JWT (özünü təmin edən). Onların arasında seçim autentifikasiya sisteminin layihələndirilməsində əsas arxitektura qərarlarından biridir.

Opaque vs JWT

Opaque token ani giriş ləğvi və mərkəzləşdirilmiş hüquq yoxlaması tələb olunan sistemlər üçün üstünlük təşkil edir. JWT — performans və şəbəkə sorğularının minimuma endirilməsinin vacib olduğu mikroxidmət arxitekturası üçün. Bir çox provayderlər (Auth0, Keycloak) hər iki formatı dəstəkləyir və hər müştəri üçün token növünü konfiqurasiya etməyə imkan verir. Opaque və JWT arasında seçim nəzarət və performans arasında kompromisdir: opaque serverə tam nəzarət verir, JWT — minimal gecikmə.

Access Token-in həyat dövrü

Access token-in həyat dövrü dörd fazadan ibarətdir: buraxılış (issuance), ötürülmə, istifadə və müddətin bitməsi. Hər fazanın öz təhlükəsizlik tələbləri və protokol məhdudiyyətləri var.

Müddətin bitməsi və yenilənməsi

Access token məhdud ömür müddətinə malikdir — adətən 15–60 dəqiqə. expires_in dəyəri token buraxılarkən avtorizasiya serverinin cavabında göstərilir. Bu müddət bitdikdən sonra token etibarsız olur və müştəri refresh token mexanizmi vasitəsilə yenisini almalıdır. Müştəri müddətin bitməsini iki yolla yoxlaya bilər: JWT-də exp sahəsi ilə (lokal) və ya HTTP 401 cavabı ilə (opaque token üçün).

Auth0 Best Practices, 2025 məlumatlarına görə, mobil tətbiqetmələr üçün optimal TTL 15–30 dəqiqədir. Çox qısa TTL (5 dəqiqədən az) hər yeniləmədə token endpoint-ə həddindən artıq yük yaradır — 10 000 istifadəçi və 5 dəqiqə TTL ilə server pik saatlarda dəqiqədə 2 000-ə qədər yeniləmə sorğusu alır. Çox uzun TTL (2 saatdan çox) token sızması zamanı hücum pəncərəsini artırır — təcavüzkar giriş avtomatik bloklanana qədər kompromitə olunmuş tokendən saatlarla istifadə edə bilər.

Access Token təhlükəsizliyi

Access token təhlükəsizliyi bütün mərhələlərdə təmin olunmalıdır: cihazda saxlanarkən, şəbəkə ilə ötürülərkən və serverdə işlənərkən. Əsas tövsiyə — access tokeni digər tətbiqetmələr və ya proseslər üçün əlçatan yerlərdə saxlamamaqdır.

Saxlama və ötürmə zamanı qorunma

Mobil cihazlarda access token saxlanılır: iOS-da — kSecAttrAccessibleAfterFirstUnlock atributu ilə Keychain-də (token ilk açılmadan sonra, hətta cihaz bloklandıqda belə əlçatandır — fon yeniləmələri üçün); Android-də — EncryptedSharedPreferences-də. Access token heç vaxt NSUserDefaults, SharedPreferences, xarici yaddaşdakı fayllarda və ya tətbiqetmə loglarında saxlanılmamalıdır. Ötürmə zamanı — yalnız TLS 1.3 və ya 1.2 ilə HTTPS. Hər API sorğusu üçün access token URL parametrlərində (query string) deyil, Authorization: Bearer başlığında ötürülməlidir — URL serverlərin və brauzerlərin loglarına düşür.

OWASP Mobile Top 10, 2025 məlumatlarına görə, cihazda tokenlərin düzgün saxlanılmaması (M1: Improper Platform Usage) və təhlükəsiz olmayan məlumat ötürülməsi (M3: Insecure Communication) hesabların kompromitə olunmasına səbəb olan ən geniş yayılmış mobil zəifliklər üçlüyünə daxildir. Əlavə tədbir — access token ilə bütün sorğular üçün certificate pinning istifadəsi: müştəri server sertifikatını təkcə standart CA zənciri ilə deyil, həm də əvvəlcədən saxlanılmış sertifikat izi (SHA-256 fingerprint) ilə yoxlayır. Bu, hətta kompromitə olunmuş CA halında belə man-in-the-middle hücumlarının qarşısını alır.

Kotlin-də kod nümunəsi

Aşağıda Android üçün Kotlin dilində access token-in Authorization başlığında göndərilməsi və refresh token vasitəsilə avtomatik yeniləmə ilə 401-in işlənməsi nümunəsi verilmişdir. Custom Interceptor ilə OkHttp istifadə olunur.

data class TokenStore {
    fun getAccessToken(): String? {
        // EncryptedSharedPreferences-dən oxuma
        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}")
}

Nümunədə iki yanaşma göstərilmişdir: avtomatik token idarəetməsi üçün OkHttp Interceptor istifadəsi və HttpURLConnection vasitəsilə birbaşa göndərmə. OkHttp Interceptor üstünlük təşkil edir — o, tokenin əlavə edilməsi və yenilənməsi məntiqini mərkəzləşdirir, hər sorğuda kodun təkrarlanmasını aradan qaldırır. Bütün sorğular cavab statusunu yoxlayan və lazım olduqda proqramçının iştirakı olmadan tokeni yeniləyən vahid interceptor-dan keçir.