Keputusan untuk mengadopsi passkey sebagai metode login utama kini memasuki fase yang lebih matang seiring pembaruan perangkat lunak identitas terbuka, Keycloak 26.7.0. Versi teranyar ini menambahkan opsi kebijakan WebAuthn baru yang membuat perilaku passkey lebih dapat diprediksi lintas perangkat dan ekosistem. Perubahan intinya terletak pada pengaturan Discoverable Credential yang kini mendukung nilai required, preferred, dan discouraged, menggantikan opsi ya-tidak yang usang.
Penyesuaian tersebut bukan sekadar penyempurnaan teknis belaka. Keycloak mencatat bahwa format baru selaras dengan spesifikasi WebAuthn terkini serta meningkatkan kompatibilitas dengan penyedia passkey populer seperti iCloud Keychain, Google Password Manager, dan 1Password. Opsi lama bernama Require Discoverable Credential resmi usang dan akan dibuang pada rilis mendatang. Implikasi produk jauh lebih luas: transisi passkey kini menguji ketelitian tim dalam merancang pengalaman pengguna, bukan lagi sekadar ketersediaan teknologi.
Passkey memang sudah berhenti menjadi gagasan autentikasi di masa depan. Pengguna menjumpainya di aplikasi seluler, peramban, pengelola kata sandi, hingga peralatan perusahaan dan platform konsumen. Penyedia identitas berlomba menyetel preferensi agar perilaku passkey seragam. Namun, tidak setiap produk perangkat lunak sebagai layanan (SaaS) layak menghapus kata sandi dalam waktu dekat.
Pertanyaan yang lebih pragmatis muncul: di mana posisi passkey dalam alur login, dan cadangan apa yang tersisa saat metode itu gagal di sisi pengguna? Keycloak 26.7.0 memberi sinyal bahwa standardisasi server perlu sejalan dengan kesiapan klien. Tanpa penyelarasan, passkey justru menciptakan risiko putus akses.
Autentikasi merupakan lapisan keamanan sekaligus bagian dari pengalaman produk. Login yang terlalu longgar membuka celah ancaman, sementara login yang rumit memicu tingkat hunus pengguna, beban layanan bantuan, dan masalah pemulihan akun. Passkey menawarkan ketahanan terhadap phishing dan mengurangi gesekan kata sandi, tetapi memunculkan serangkaian pertanyaan operasional yang harus dijawab tim sebelum menjadikannya bawaan.
Di Indonesia, tren adopsi passkey mulai terlihat pada ekosistem perbankan digital dan layanan pemerintah yang menjangkau jutaan pengguna. Mayoritas memakai perangkat Android dengan Google Password Manager sebagai penyimpan kredensial tersinkronisasi. Kehadiran setelan Discoverable Credential yang mendukung preferred atau discouraged memberi ruang bagi pengembang lokal untuk menyesuaikan dengan kondisi jaringan dan variasi perangkat kelas bawah. Kendati demikian, banyak perusahaan masih mengandalkan kata sandi plus MFA SMS yang rentan intercept.
Perbandingan dengan situasi global menunjukkan bahwa pengguna Indonesia sering berpindah perangkat dan meminjam ponsel, sehingga passkey berbasis perangkat tunggal bisa menyulitkan. Produk yang menyasar pelaku usaha mikro kecil menengah (UMKM) wajib mempertimbangkan pemulihan akun terpusat. Tanpa strategi fallback, migrasi mendadak justru meningkatkan tiket dukungan teknis.
Aspek kepatuhan juga relevan. Otoritas seperti OJK dan Bank Indonesia telah mendorong autentikasi multifaktor, namun belum secara spesifik mewajibkan passkey. Oleh karena itu, penyelenggara layanan di tanah air dapat menjadikan pembaruan Keycloak sebagai referensi arsitektur sebelum menetapkan kebijakan keamanan yang dapat dijelaskan kepada tim dukungan dan kesuksesan pelanggan.
Tim pengembang Keycloak dalam catatan rilis menegaskan bahwa server harus memberi tahu peramban apakah kredensial yang dapat ditemukan diperlukan, karena objek tersebut kerap disimpan di perangkat atau pengelola kata sandi pengguna. Pernyataan itu menggarisbawahi bahwa keberhasilan passkey bergantung pada negosiasi antara sistem identitas dan lingkungan klien, bukan sekadar menyalakan sakelar di sisi backend.
Perspektif serupa muncul dari praktisi keamanan yang mengingatkan bahwa passkey tidak boleh dipandang sebagai peluru perak. Enam area evaluasi perlu menyertai rollout: pemahaman profil pengguna, pengujian lingkungan peramban dan sistem operasi, penyiapan alur pemulihan, peluncuran bertahap, penetapan kebijakan peran, serta pengukuran metrik. Semua itu menuntut kolaborasi lintas fungsi produk, keamanan, dan operasi.
Langkah maju dapat dimulai dengan menawarkan passkey sebagai metode opsional setelah login kata sandi sukses, lalu mendorong pendaftaran bertahap. Akun dengan risiko tinggi seperti administrator dapat diwajibkan menggunakan passkey setelah data pemulihan kuat. Penurunan kata sandi baru dilakukan jika metrik menunjukkan penurunan permintaan reset dan keluhan dukungan.
Ke depan, rollout passkey akan bergeser dari eksperimen menjadi standar bagi portal admin, alur keuangan, dan dasbor pelanggan bernilai tinggi. Namun bagi produk dengan akun bersama atau integrasi warisan, kehati-hatian tetap diperlukan. Transisi yang disertai cadangan tepat akan menentukan apakah passkey benar-benar mengurangi risiko atau justru memutus akses pengguna setia.