Saya Coba Pasang Login Passkey di Project Client: Apa yang Beneran Kejadian

Salah satu client saya jalanin web app subscription kecil, dan tahun ini support ticket yang paling sering muncul bukan bug — tapi reset password. Password lupa, password yang dipake ulang kena flag dari tool breach-monitoring, sesekali ada percobaan phishing ke inbox support mereka yang ngaku-ngaku user yang ke-lock out. Passkey udah keliatan jadi jawaban yang obvious dari dulu — full didukung browser dan OS, nggak ada shared secret yang bisa dipancing, nggak ada password yang dipake ulang di banyak site. Jadi saya beneran implementasi di project ini, bukan cuma baca artikel “passkey itu masa depan” lagi, dan hasilnya lebih campur aduk dari yang keliatannya dari antusiasme di internet.

Implementasi teknisnya sendiri itu bagian yang gampang, dan itu ngagetin saya. Saya pakai library WebAuthn di backend Node buat handle registration sama authentication ceremony-nya, tambahin call navigator.credentials di sisi browser, dan simpen public key credential-nya ke akun user. Satu weekend kerja fokus udah cukup buat dapetin flow passkey yang jalan end-to-end di dev environment. Kalau kamu pernah ngerjain auth sebelumnya, kriptografi dan protocol handling-nya beneran udah bukan bagian susah lagi — library-nya udah cukup matang sekarang, jalan yang udah banyak diinjek orang, bukan project riset.

Yang beneran ribet itu account recovery, dan saya underestimate ini parah. Gimana kalau HP orang yang punya passkey-nya rusak, ilang, atau diganti? Sama password, recovery-nya nyebelin tapi konsepnya simpel — reset lewat email. Sama passkey yang nempel di secure enclave device, kehilangan device itu tanpa backup yang tersinkron artinya kehilangan credential-nya sepenuhnya, kecuali kamu udah rencanain dari awal. Akhirnya saya tetep pertahankan password-plus-email-OTP sebagai fallback permanen ketimbang sistem passkey-only, spesifik karena saya nggak mau ngedesain diri saya masuk pojokan di mana HP ilang artinya customer yang bayar jadi ke-lock out tanpa jalur recovery yang jelas.

Behavior sync antar-device itu beda-beda cukup jauh antar ekosistem sampai saya harus test jauh lebih banyak kombinasi dari yang saya kira. Passkey yang dibikin di iPhone sync lewat iCloud Keychain; yang dibikin di Android sync lewat Google Password Manager; passkey yang dibikin di laptop kantor pakai hardware key kelakuannya beda lagi. Testing “ini jalan apa nggak” bukan satu test case, realistisnya delapan sampai sembilan kombinasi antara browser, versi OS, dan apakah orangnya pakai device pribadi atau device kantor yang di-lock down. Saya nemu paling nggak dua kombinasi — Android WebView versi lama dan profile Chrome kantor dengan policy restriction — di mana flow-nya gagal diem-diem dengan cara yang ngasih user error yang membingungkan, bukan penjelasan yang jelas.

Bagian yang cocok sama yang saya baca soal adopsi stagnan itu reaksi user beneran, bukan teknologinya. Pas saya nawarin login passkey sebagai opsi, saya perhatiin beberapa user non-teknis nyoba pas soft rollout, dan kebingungannya bukan soal mekanismenya — Face ID atau prompt fingerprint itu udah cukup intuitif — tapi soal konsepnya. “Lho, jadi saya nggak punya password lagi buat ini? Gimana kalau ganti HP?” itu pertanyaan yang wajar banget dan banyak onboarding copy yang sebenernya belum jawab itu. Beberapa user yang mulai flow setup passkey batal di tengah jalan, bukan karena rusak, tapi karena mereka nggak yakin lagi setuju sama apa.

Di bulan pertama setelah soft rollout, adopsinya kayak gini: minoritas kecil user yang melek teknologi langsung pindah hampir seketika, sebagian besar orang cuek aja sama opsinya dan tetep pakai password, dan beberapa nyoba terus balik lagi ke login password dalam beberapa hari. Itu kurang lebih konsisten sama narasi “adopsi stagnan” yang muncul di tulisan-tulisan industri tahun ini — teknologinya jalan, tapi banyak user biasa yang belum punya mental model yang jelas soal apa sebenernya passkey itu atau kenapa itu lebih baik dari yang udah mereka pake.

Hal yang beneran ngerubah keadaan lebih dari kerjaan backend manapun itu nulis ulang onboarding copy. Versi pertama saya ngejelasin passkey dari sisi teknologinya — “kredensial kriptografi yang disimpen di device kamu.” Nggak ada yang peduli. Versi yang beneran bikin lebih banyak orang nyoba cuma bilang “login pakai Face ID atau fingerprint kamu, nggak perlu ngetik password” dan nunjukin persis kayak apa prompt-nya sebelum mereka tap apapun. Ini bukan pelajaran engineering, lebih ke pengingat kalau solusi teknis yang beneran lebih bagus itu nggak otomatis kejual sendiri cuma karena secara teknis lebih bagus.

Rekomendasi beneran saya buat siapapun yang mau bangun ini di project client sekarang: bikin sebagai tambahan, bukan pengganti, dan jangan skip cerita recovery-nya. Passkey itu jelas layak ditawarin — properti keamanannya nyata dan cost implementasinya sama library modern beneran rendah. Tapi kalau diperlakukan sebagai pengganti penuh login berbasis password sekarang, buat audience consumer umum yang belum tentu udah paham konsepnya, itu artinya ngedesain pengalaman yang lebih buruk buat sebagian besar user client ini, bukan lebih baik.

Saya bakal terus pantau adopsinya di project ini beberapa bulan ke depan, karena menurut saya gambarannya berubah di jangka waktu yang lebih panjang dari yang bisa ditunjukin satu soft rollout. User yang udah pindah ke passkey belum ada yang balik lagi, dan support ticket dari grup itu turun hampir ke nol, yang itu hasil yang beneran bagus walaupun adopsinya masih rendah. Tebakan saya ini bakal ngikutin kurva yang sama kayak two-factor authentication bertahun-tahun lalu — awalnya lambat, kebanyakan power user, sampai cukup banyak ekosistem yang default ke situ sampai berhenti kerasa kayak pilihan yang aneh. Saya cuma nggak mau pura-pura kurva itu udah kejadian cuma dari data satu bulan di satu app client.