Wawancara Frontend: Bagaimana Anda meluncurkan WebAuthn conditional create secara aman?

Perintah dan konteks yang berlaku

Produk ini telah mendukung login nama pengguna/kata sandi dan conditional get untuk masuk menggunakan passkey. Anda ingin menggunakan WebAuthn Level 3 conditional create setelah login dengan tingkat kepercayaan tinggi (high-trust), yang menyarankan passkey tanpa mengganggu alur. Jelaskan deteksi kemampuan browser, gerbang pembuatan (creation gates), validasi server, batas privasi, dan rollback.

Fokus ini ada pada platform Web dan UX autentikasi. Dukungan API browser tidak berarti perangkat memiliki autentikator yang dapat digunakan; pembuatan tetap memerlukan persetujuan pengguna dan verifikasi server.

Apa yang dievaluasi oleh pewawancara

• Apakah Anda membedakan conditional create, conditional get, dan pembuatan berbasis tombol secara eksplisit.
• Apakah Anda menghubungkan kemampuan, kebijakan, status akun, dan sinkronisasi lintas perangkat ke dalam gerbang yang jelas.
• Apakah Anda mencegah kredensial duplikat, salah pengikatan (misbinding) akun, kebocoran keberadaan kredensial, dan login kata sandi yang terhalang.
• Apakah Anda dapat melakukan rilis canary dan menarik kembali fitur tersebut daripada mengaktifkan API baru di semua tempat.

Jawaban yang kuat memperlakukan conditional create sebagai peningkatan progresif: upaya yang tidak didukung, dibatalkan, atau habis waktu (timed-out) membiarkan alur utama tidak berubah, sementara server tetap memverifikasi challenge, origin, RP ID, dan pengikatan akun.

Pertanyaan klarifikasi sebelum menjawab

1. Apakah targetnya adalah setiap pengguna yang masuk, atau hanya pengguna dengan email terverifikasi, MFA, atau autentikasi ulang berisiko tinggi baru-baru ini?
2. Apakah passkey yang disinkronkan multi-perangkat diizinkan? Hal itu mengubah persyaratan pemulihan dan pencabutan.
3. Apakah halaman tersebut sudah memiliki permintaan credentials.create() yang tertunda? Permintaan yang bersamaan membuat prompt tidak dapat diprediksi.
4. Ketika conditional create tidak tersedia, haruskah Anda menampilkan tombol eksplisit “Buat passkey” atau menyembunyikan fitur tersebut?

Kerangka kerja jawaban 30 detik

“Saya akan mendeteksi kemampuan conditional-create, lalu menggabungkan status akun, kekuatan autentikasi terkini, dan feature flag server sebelum mencobanya. Klien memulai paling banyak satu permintaan pada momen eksplisit yang disetujui pengguna dan membatalkan duplikat dengan AbortController; upaya yang tidak didukung, dibatalkan, atau timed out kembali ke alur awal. Server mengikat challenge sekali pakai ke pengguna, origin, RP ID, dan kedaluwarsa, lalu menyimpan kredensial hanya setelah verifikasi. Selama canary, saya akan melacak keberhasilan pembuatan, pembatalan, kredensial duplikat, fallback kata sandi, dan tiket pemulihan. Sebuah insiden akan menonaktifkan flag; kredensial yang ada masih dapat digunakan atau dicabut secara terpisah.”

Jawaban mendalam langkah demi langkah

1. Pisahkan kedua interaksi kondisional

Conditional get memungkinkan pengguna memilih passkey yang ada saat memasukkan akun; conditional create menyarankan pendaftaran kredensial baru dalam konteks formulir. Keduanya bergantung pada kemampuan browser dan autentikator, sehingga hanya memeriksa objek PublicKeyCredential tidaklah cukup.

Deteksi kemampuan menentukan apakah akan mencoba, bukan apakah akan mengotorisasi. Server harus tetap mengikat pendaftaran ke pengguna yang saat ini diautentikasi dan mencatat sumber pembuatan serta versi kebijakan.

2. Tentukan gerbang pembuatan

Wajibkan semua hal berikut: browser melaporkan kemampuan conditional-create; pengguna baru-baru ini menyelesaikan autentikasi yang memadai; akun tidak sedang dalam pemulihan, penggabungan, atau perubahan berisiko tinggi; dan flag server mengaktifkan tenant serta segmen lalu lintas. Pada perangkat baru, jelaskan manfaatnya dan biarkan pengguna melanjutkan alih-alih membuat passkey saat halaman dimuat.

3. Cegah duplikat dan race condition

Izinkan satu permintaan pembuatan per sesi halaman. Batalkan permintaan sebelumnya sebelum memulai yang lain dan batalkan saat komponen di-unmount. Challenge server bersifat sekali pakai, ID kredensial memiliki batasan unik, dan pengiriman duplikat mengembalikan hasil yang idempoten daripada membuat baris baru.

capability -> policy gate -> one challenge -> user consent
      |            |               |
   fallback   feature flag     server verify -> persist

4. Validasi pendaftaran sepenuhnya

Server memverifikasi challenge, origin, RP ID, tanda tangan, user handle, kebijakan pengesahan (attestation), dan ID kredensial. Jangan pernah memercayai hasil "created" dari sisi klien. Jika pengesahan perangkat tidak diperlukan, pilih kebijakan pengesahan yang lebih sederhana dan nyatakan trade-off antara privasi dan risiko.

5. Tangani sinkronisasi dan pemulihan

Passkey yang disinkronkan mungkin muncul setelah pengguna berganti perangkat, tetapi sinkronisasi bukanlah pemulihan akun. Sediakan daftar kredensial, pencabutan kredensial tunggal, dan jalur pemulihan untuk pengguna yang kehilangan semua perangkat. Jangan ungkapkan keberadaan passkey ke permintaan yang tidak diautentikasi.

6. Rilis canary dengan telemetri yang berguna

Aktifkan berdasarkan browser, platform, tenant, dan tingkat risiko. Catat deteksi kemampuan, tampilan prompt, persetujuan, kegagalan verifikasi, pembatalan/timeout, kredensial duplikat, fallback kata sandi, dan tiket dukungan. Pisahkan antara “tidak didukung” dan “ditolak pengguna”; jika tidak, Anda tidak dapat mengetahui apakah harus memperbaiki salinan teks (copy) atau menonaktifkan fitur tersebut.

7. Rollback tanpa merusak akun

Gunakan flag jarak jauh untuk menghentikan upaya pembuatan baru sambil mempertahankan login passkey yang ada. Jangan pernah menghapus kredensial sebagai bagian dari rollback rilis; pencabutan adalah operasi akun. Pertahankan batas jendela kompatibilitas untuk versi challenge yang lebih lama dan jalankan kembali pengujian browser serta autentikator saat perilaku berubah.

Contoh jawaban berkualitas tinggi

Saya akan merilis conditional create sebagai peningkatan yang dapat dibatalkan (reversible enhancement). Klien mendeteksi kemampuan, lalu memeriksa status akun, kekuatan autentikasi terkini, dan feature flag; satu permintaan per halaman diberlakukan dan AbortController membatalkan duplikat. Server membuat challenge sekali pakai dan memverifikasi challenge, origin, RP ID, tanda tangan, dan ID kredensial sebelum persistensi. Upaya yang tidak didukung, dibatalkan, atau timed out kembali ke login kata sandi dan tidak pernah menjadi kegagalan login. Saya akan melakukan canary berdasarkan platform dan risiko sambil melacak kemampuan, persetujuan, kesalahan verifikasi, kredensial duplikat, fallback, dan tiket pemulihan. Menonaktifkan flag akan menghentikan pembuatan baru tetapi tetap menyediakan passkey yang ada dan fungsi pencabutan.

Kesalahan umum

• Kesalahan → hanya memeriksa apakah PublicKeyCredential ada → objek tersebut tidak membuktikan bahwa conditional create atau autentikator tersedia; perbaikan: gunakan deteksi kemampuan dan pertahankan fallback.
• Kesalahan → secara diam-diam memanggil create saat halaman dimuat → pengguna tidak memberikan persetujuan dan kemungkinan muncul prompt duplikat; perbaikan: picu pada momen eksplisit dengan tingkat kepercayaan tinggi dan biarkan pengguna melanjutkan.
• Kesalahan → memercayai hasil sukses dari sisi klien → challenge, origin, atau pengikatan akun mungkin belum diverifikasi; perbaikan: selesaikan verifikasi pendaftaran di server.
• Kesalahan → menghapus kredensial baru selama rollback → rollback rilis menjadi perusakan akun; perbaikan: nonaktifkan pembuatan baru dan kelola pencabutan secara terpisah.

Pertanyaan lanjutan dan tanggapan

Haruskah Anda meminta konfirmasi setiap hari setelah pengguna menolak?

Tidak. Catat cooldown lokal dan versi kebijakan. Tanyakan lagi hanya jika risiko akun, perangkat, atau kondisi produk berubah secara material; penolakan tidak boleh memengaruhi login kata sandi.

Bagaimana jika akun yang sama memiliki dua baris dengan ID kredensial yang sama?

Jadikan ID kredensial unik, jadikan pendaftaran idempoten, dan catat sumbernya. Jika duplikat sudah ada, bekukan penulisan baru dan gabungkan atau tinjau berdasarkan pengguna dan ID kredensial; jangan pernah menimpa salah satunya secara diam-diam.

Kemampuan didukung tetapi tingkat keberhasilan tiba-tiba turun. Apa yang Anda periksa terlebih dahulu?

Bagi berdasarkan versi browser, platform, autentikator, dan kode kesalahan untuk memisahkan pembatalan, batas waktu, penolakan kebijakan, dan kegagalan verifikasi server. Jeda kohort flag yang terpengaruh, pertahankan login kata sandi dan passkey yang ada, perbaiki penyebabnya, dan validasi ulang dengan kohort kecil.