7 Cara Menyimpan Token Login di iOS dan macOS

Menyimpan token login di iOS dan macOS berarti memilih tempat yang tahan terhadap pencurian data sekaligus mudah dibaca ulang setelah aplikasi ditutup. Dari tujuh opsi di bawah, Keychain adalah pilihan default untuk sebagian besar kasus, tetapi ada situasi di mana opsi lain lebih masuk akal. Perbandingan ini menjelaskan kapan masing-masing layak dipakai dan apa risikonya.

1. Keychain sebagai penyimpanan utama

Keychain menyimpan data terenkripsi di tingkat sistem dan mengunci aksesnya berdasarkan aplikasi yang menulis. Di iOS, token tetap terisolasi meskipun perangkat di-jailbreak ringan; di macOS, Keychain dibuka dengan kredensial login pengguna. API-nya sudah menangani enkripsi, sehingga kode aplikasi tidak pernah menyentuh kunci enkripsi secara langsung.

Pakai kSecClassGenericPassword untuk token, bukan kSecClassInternetPassword yang lebih cocok untuk kredensial server yang sudah dikenal sistem. Atur kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly agar token bisa dibaca proses latar belakang setelah pengguna membuka kunci perangkat sekali, tanpa ikut tersalin ke perangkat baru lewat backup.

let query: [String: Any] = [
    kSecClass as String: kSecClassGenericPassword,
    kSecAttrService as String: "com.contoh.app",
    kSecAttrAccount as String: "refreshToken",
    kSecAttrAccessible as String: kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly,
    kSecValueData as String: tokenData
]
SecItemAdd(query as CFDictionary, nil)

Kekurangannya, API Keychain berbasis C dan mudah salah pakai. Salah memasang atribut aksesibilitas bisa membuat token tidak terbaca setelah perangkat di-restart, atau sebaliknya, ikut tersalin ke iCloud Keychain padahal seharusnya terikat ke satu perangkat saja.

2. Keychain dengan biometrik sebagai gerbang tambahan

Token tetap disimpan di Keychain, tetapi Anda meminta autentikasi Face ID atau Touch ID sebelum membacanya. Pola ini cocok untuk aplikasi yang menangani data sensitif dan diakses berulang kali dalam sehari, misalnya aplikasi perbankan atau pencatat kesehatan.

Biaya yang timbul adalah latensi. Setiap panggilan ke token memerlukan gestur pengguna, jadi simpan token di memori setelah otentikasi pertama dan jangan membaca ulang dari Keychain untuk setiap permintaan jaringan. Siapkan juga rencana cadangan ketika biometrik gagal, misalnya lewat kode sandi perangkat.

3. App Group Keychain untuk aplikasi dan ekstensi

Aplikasi yang punya widget, ekstensi keyboard, atau ekstensi berbagi punya beberapa proses berjalan bersamaan. Keychain biasa mengikat item ke aplikasi penulisnya, sehingga ekstensi tidak bisa membacanya. Solusinya adalah App Group, yang diberikan sebagai kSecAttrAccessGroup.

Tentukan satu grup untuk seluruh target aplikasi dan pastikan hak aksesnya terdaftar di setiap target. Tanpa itu, penulisan akan gagal dengan status errSecMissingEntitlement. Grup ini juga membuka kemungkinan ekstensi menghapus token saat logout, sehingga pengguna tidak tertinggal dalam keadaan setengah masuk.

4. UserDefaults, hanya untuk data yang tidak sensitif

UserDefaults duduk di dalam berkas plist yang bisa dibaca dengan mudah dari backup atau perangkat yang sudah diakses. Token login di UserDefaults praktis setara dengan menempelkannya di layar. Meskipun begitu, UserDefaults tetap berguna untuk menyimpan penanda seperti alamat server, waktu kedaluwarsa, atau status “ingat saya” yang hanya mengatur alur UI.

Jika aplikasi Anda sudah menyimpan banyak preferensi, pola penyimpanan pengaturan yang rapi membantu memisahkan mana yang aman dan mana yang harus pindah ke Keychain. Rujukan lengkapnya ada di cara menyimpan data pengaturan di aplikasi iOS dan macOS.

5. Berkas terenkripsi dengan kunci dari Keychain

Untuk token berukuran besar atau struktur yang kompleks, misalnya sesi dengan banyak cakupan izin, menyimpan seluruh blob JSON di Keychain terasa janggal karena batas praktis ukuran item. Alternatifnya, enkripsi blob dengan AES-GCM menggunakan kunci simetris yang disimpan di Keychain, lalu tulis hasilnya ke folder Application Support.

Pola ini memberi keleluasaan format dan memudahkan rotasi kunci. Namun Anda harus mengurus sendiri penghapusan berkas saat logout, penanganan kegagalan dekripsi, dan migrasi kunci ketika skema berubah. Kesalahan pada salah satu titik tersebut bisa meninggalkan token aktif di disk jauh setelah pengguna keluar.

6. SwiftData atau Core Data dengan enkripsi tambahan

Menyatukan token ke dalam basis data lokal memudahkan pengelolaan ketika aplikasi sudah punya banyak entitas pengguna. Sayangnya, SwiftData dan Core Data tidak mengenkripsi isi basis data secara default. Proteksi baru muncul dari file protection sistem dan enkripsi disk perangkat, yang tidak cukup ketika perangkat terbuka atau data ikut tercadangkan.

Jika memilih jalur ini, enkripsi kolom token sebelum disimpan dan simpan kuncinya di Keychain. Simpan hanya token penyegar jangka panjang di basis data, sementara token akses berumur pendek tetap di memori. Perbandingan mendalam soal basis data lokal bisa dibaca di SwiftData vs Core Data untuk aplikasi iOS.

7. Memori saja tanpa penyimpanan permanen

Opsi paling aman adalah tidak menyimpan token sama sekali. Pengguna memasukkan kredensial setiap kali aplikasi dibuka, dan token akses hidup hanya selama proses berjalan. Cocok untuk aplikasi dengan frekuensi pemakaian rendah atau lingkungan bersama, misalnya kios atau perangkat laboratorium.

Untuk aplikasi konsumen, keputusan ini menambah gesekan yang nyata. Pengguna akan beralih ke aplikasi lain yang tetap mengingat sesi mereka. Jalan tengahnya adalah token berumur pendek yang disimpan di memori ditambah refresh token di Keychain, sehingga sesi tetap berlanjut tanpa menyimpan kredensial jangka panjang di tempat yang mudah dibaca.

Membandingkan risiko dan biaya implementasi

Kebiasaan yang menentukan keamanan token

Pilihan penyimpanan hanya separuh cerita. Sisanya ditentukan oleh cara aplikasi memperlakukan token setelah dibaca. Beberapa kebiasaan berikut menutup celah yang paling sering muncul.

• Hapus token dari Keychain saat logout, bukan hanya mengosongkan state di memori.
• Jangan pernah menulis token ke log, baik lewat print maupun pencatatan ke layanan pihak ketiga.
• Batasi token ke satu perangkat dengan atribut ThisDeviceOnly bila sesi tidak seharusnya berpindah.
• Perbarui token akses sebelum kedaluwarsa, dan tangani kegagalan refresh sebagai kondisi logout penuh.
• Uji skenario penghapusan aplikasi, pemulihan dari backup, dan perubahan kode sandi perangkat.

Saat menguji alur otentikasi, siapkan juga skenario jaringan lambat atau terputus. Token yang disegarkan di tengah koneksi yang buruk sering memunculkan kondisi balapan yang sulit direproduksi. Metode pengujian latensi berkala bisa membantu menyiapkan kondisi tersebut secara konsisten, seperti dijelaskan pada 7 metode uji latensi jaringan secara berkala.

Untuk aplikasi yang juga menyimpan data pengguna lain di perangkat, pertimbangkan bagaimana data lama dibersihkan ketika akun dihapus. Panduan cara menghapus jejak digital memberi gambaran umum tentang pembersihan data yang bisa diterapkan pada alur penghapusan akun di aplikasi.

Keychain tetap menjadi titik awal yang tepat untuk token login. Tambahkan biometrik bila data yang dilindungi memang sensitif, dan pakai App Group ketika ada ekstensi. Hindari UserDefaults dan basis data lokal tanpa enkripsi untuk token apa pun yang bisa dipakai membuka akun.

Pertanyaan yang Sering Diajukan

Apakah token di Keychain ikut tersalin saat pengguna pindah perangkat?

Tergantung atribut aksesibilitasnya. Atribut yang mengandung ThisDeviceOnly mencegah item ikut ke backup dan perangkat baru. Tanpa atribut itu, item bisa berpindah lewat backup terenkripsi atau iCloud Keychain, yang belum tentu Anda inginkan untuk refresh token.

Bisakah Keychain dipakai di macOS dan iOS dengan kode yang sama?

API-nya sama, tetapi hak akses dan perilaku penyimpanan berbeda. Di macOS, item terikat pada identitas penandatangan aplikasi dan bisa memunculkan dialog izin akses. Uji kedua platform secara terpisah, terutama saat aplikasi dibangun dengan sandbox aktif.

Apa yang harus dilakukan jika token diduga bocor?

Cabut token di sisi server, hapus dari penyimpanan lokal, dan minta pengguna masuk ulang. Periksa juga apakah token sempat tercatat di log atau tersimpan di tempat yang tidak semestinya. Untuk aplikasi produksi, pertimbangkan konsultasi dengan tim keamanan sebelum memutuskan cakupan pencabutan.