Access Token dalam pengembangan iOS dan Android — konsep kunci, jenis token, dan cara kerjanya

Apa itu Access Token?

Access Token — adalah string yang digunakan klien (aplikasi seluler, SPA, server) untuk mengautentikasi permintaan HTTP ke endpoint API yang dilindungi. Token dikeluarkan oleh server otorisasi setelah pengguna mengonfirmasi identitasnya dan memberikan izin yang sesuai (scope) kepada aplikasi.

Access token adalah elemen sentral dari protokol OAuth 2.0 dan semua sistem yang dibangun di atasnya — OpenID Connect, Firebase Authentication, Auth0, Keycloak. Tanpa access token, tidak ada permintaan ke API yang dilindungi yang akan diproses: server mengembalikan HTTP 401 Unauthorized. Token tidak mengidentifikasi pengguna secara langsung — token menegaskan bahwa klien memiliki hak untuk melakukan tindakan tertentu atas nama pengguna (otorisasi), bukan siapa pengguna tersebut (autentikasi).

Menurut data Okta, 2025, lebih dari 80% API publik menggunakan skema Bearer dengan access token di header Authorization, menggantikan metode autentikasi usang — Basic Auth dan API Key. Access token juga merupakan dasar untuk delegated authorization — model di mana pengguna memberikan aplikasi akses terbatas ke datanya di layanan lain. Misalnya, ketika aplikasi seluler pengedit foto meminta akses ke Google Drive melalui OAuth 2.0, pengguna melihat layar persetujuan dengan scope spesifik yang tercantum dan setelah konfirmasi menerima access token dengan hak-hak tersebut.

Bagaimana Access Token Bekerja

Mekanisme kerja access token didasarkan pada skema Bearer: klien menambahkan header Authorization: Bearer <token> ke setiap permintaan HTTP. Server sumber daya (API) menerima token, memeriksa validitasnya, dan menentukan sumber daya apa yang tersedia. Pemeriksaan dapat dilakukan dengan dua cara: secara lokal (untuk JWT) atau melalui introspection endpoint (untuk opaque token).

Skema Bearer Token

Bearer token berarti siapa pun yang menunjukkan token (bearer — pembawa) mendapatkan akses yang sesuai. Ini menimbulkan persyaratan tinggi untuk perlindungan token selama transmisi dan penyimpanan. Skema Bearer tidak mengharuskan klien untuk membuktikan kepemilikan token secara kriptografis — cukup dengan mengirimkannya saja. Oleh karena itu, HTTPS adalah wajib: tanpa enkripsi lalu lintas, penyerang dapat mencegat token dan segera menggunakannya.

Menurut data Cloudflare, 2025, intersepsi Bearer token melalui koneksi HTTP yang tidak diamankan terjadi rata-rata dalam 12 detik setelah permintaan dikirim. Penggunaan HTTPS dan TTL pendek access token (15–30 menit) mengurangi risiko hingga hampir nol. Perlindungan tambahan di tingkat aplikasi — verifikasi asal permintaan melalui OAuth 2.0 Token Binding (RFC 8471): klien membuktikan kepemilikan kunci TLS yang terikat dengan token, sehingga pencurian token melalui intersepsi menjadi tidak berguna.

Jenis Access Token

Access token ada dalam dua format: opaque (tidak transparan) dan JWT (mandiri). Pilihan di antara keduanya adalah salah satu keputusan arsitektur kunci saat merancang sistem autentikasi.

Opaque vs JWT

Opaque token lebih disukai untuk sistem yang memerlukan pencabutan akses seketika dan pemeriksaan hak terpusat. JWT — untuk arsitektur mikroservis, di mana kinerja dan minimalisasi panggilan jaringan penting. Banyak penyedia (Auth0, Keycloak) mendukung kedua format dan memungkinkan pengaturan jenis token untuk setiap klien. Pilihan antara opaque dan JWT adalah kompromi antara kontrol dan kinerja: opaque memberikan kontrol penuh kepada server, JWT — latensi minimal.

Siklus Hidup Access Token

Siklus hidup access token terdiri dari empat fase: penerbitan (issuance), transmisi, penggunaan, dan kedaluwarsa. Setiap fase memiliki persyaratan keamanan dan batasan protokolnya sendiri.

Kedaluwarsa dan Pembaruan

Access token memiliki masa berlaku terbatas — biasanya 15–60 menit. Nilai expires_in ditunjukkan dalam respons server otorisasi saat token diterbitkan. Setelah waktu ini berakhir, token menjadi tidak valid dan klien harus mendapatkan token baru melalui mekanisme refresh token. Klien dapat memeriksa kedaluwarsa dengan dua cara: melalui bidang exp di JWT (secara lokal) atau melalui respons HTTP 401 (untuk opaque token).

Menurut data Auth0 Best Practices, 2025, TTL optimal access token untuk aplikasi seluler adalah 15–30 menit. TTL yang terlalu pendek (kurang dari 5 menit) menciptakan beban berlebihan pada token endpoint setiap kali pembaruan — dengan 10.000 pengguna dan TTL 5 menit, server menerima hingga 2.000 permintaan pembaruan per menit pada jam sibuk. TTL yang terlalu panjang (lebih dari 2 jam) memperbesar jendela serangan jika terjadi kebocoran token — penyerang dapat menggunakan token yang dikompromikan selama berjam-jam sebelum akses diblokir secara otomatis.

Keamanan Access Token

Keamanan access token harus dijamin di semua tahap: saat penyimpanan di perangkat, saat transmisi melalui jaringan, dan saat pemrosesan di server. Rekomendasi dasar — jangan pernah menyimpan access token di tempat yang dapat diakses oleh aplikasi atau proses lain.

Perlindungan saat Penyimpanan dan Transmisi

Di perangkat seluler access token disimpan: di iOS — di Keychain dengan atribut kSecAttrAccessibleAfterFirstUnlock (token tersedia setelah pembukaan kunci pertama, bahkan jika perangkat terkunci — untuk pembaruan latar belakang); di Android — di EncryptedSharedPreferences. Access token tidak boleh disimpan di NSUserDefaults, SharedPreferences, file di penyimpanan eksternal, atau log aplikasi. Saat transmisi — hanya HTTPS dengan TLS 1.3 atau 1.2. Untuk setiap permintaan API, access token harus dikirimkan di header Authorization: Bearer, bukan di parameter URL (query string) — URL masuk ke log server dan browser.

Menurut data OWASP Mobile Top 10, 2025, penyimpanan token yang tidak tepat di perangkat (M1: Improper Platform Usage) dan transmisi data yang tidak aman (M3: Insecure Communication) termasuk dalam tiga kerentanan seluler paling umum yang mengakibatkan kompromi akun. Tindakan tambahan — penggunaan certificate pinning untuk semua permintaan dengan access token: klien memverifikasi sertifikat server tidak hanya melalui rantai CA standar, tetapi juga melalui sidik jari sertifikat yang disimpan sebelumnya (SHA-256 fingerprint). Ini mencegah serangan man-in-the-middle bahkan jika CA dikompromikan.

Contoh Kode dalam Kotlin

Di bawah ini adalah contoh dalam Kotlin untuk Android, yang menunjukkan pengiriman permintaan dengan access token di header Authorization dan penanganan 401 dengan pembaruan otomatis melalui refresh token. OkHttp dengan Interceptor khusus digunakan.

data class TokenStore {
    fun getAccessToken(): String? {
        // Membaca dari EncryptedSharedPreferences
        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}")
}

Contoh ini menunjukkan dua pendekatan: penggunaan OkHttp Interceptor untuk manajemen token otomatis dan pengiriman langsung melalui HttpURLConnection. OkHttp Interceptor lebih disukai — ia memusatkan logika penambahan dan pembaruan token, menghilangkan duplikasi kode di setiap permintaan. Semua permintaan melewati satu interceptor yang memeriksa status respons dan jika perlu memperbarui token tanpa campur tangan pengembang.