Wawancara Frontend: Bisakah WebAuthn largeBlob menggantikan state pengguna di sisi server?

Perintah dan cakupan

Produk ingin mengikat konfigurasi terenkripsi berukuran kecil ke kredensial WebAuthn pengguna untuk mengurangi state di sisi server. Jelaskan kapan largeBlob tepat digunakan, perbedaan antara registrasi dan autentikasi, cara klien memeriksa hasil, serta bagaimana login dan kebenaran data tetap bertahan pada perangkat yang tidak mendukung.

Hal yang diuji oleh pewawancara

• Apakah Anda mengetahui bahwa largeBlob adalah data buram (opaque data) yang terkait dengan satu kredensial, bukan penyimpanan klien umum.
• Apakah Anda membedakan input dan output registrasi support dari autentikasi read dan write.
• Apakah Anda memperhitungkan kapasitas pengautentikasi (authenticator), discoverable credentials, dan batasan penulisan satu kredensial.
• Apakah Anda merancang deteksi kapabilitas, pencadangan server, privasi, dan fallback kegagalan.

Pertanyaan klarifikasi

1. Apakah data harus ikut berpindah bersama kredensial ini, ataukah basis data server dan IndexedDB sudah mencukupi?
2. Apa saja persyaratan ukuran, kerahasiaan, pemulihan, dan lintas perangkat?
3. Apakah authenticator target mendukung largeBlob, dan apakah kredensial tersebut discoverable?
4. Bagaimana sistem memulihkan diri setelah penulisan gagal, kredensial hilang, atau terjadi pergantian perangkat?

Jawaban 30 detik

Saya akan memperlakukan largeBlob sebagai kapabilitas authenticator opsional, bukan penyimpanan utama. Selama registrasi, minta support: preferred dan periksa supported; selama autentikasi, gunakan salah satu dari read atau write, targetkan tepat satu kredensial untuk operasi tulis, dan periksa blob atau written. Enkripsi dan batasi ukuran data serta simpan salinan yang dapat dipulihkan di server. Kapabilitas yang tidak didukung, kapasitas habis, atau kegagalan penulisan harus beralih (fallback) ke state server tanpa memblokir login atau menganggap penulisan yang belum terkonfirmasi sebagai berhasil.

Desain langkah demi langkah

1. Memilih batasan data yang tepat

Spesifikasi mendefinisikan largeBlob sebagai data buram yang terkait dengan suatu kredensial. Ini cocok untuk konfigurasi kecil yang terikat kredensial atau material kunci, bukan profil pengguna, sinkronisasi lintas kredensial, atau basis data objek. Authenticator memiliki kapasitas terbatas, sehingga server harus tetap menyimpan informasi pemulihan.

2. Menggunakan registrasi hanya untuk deteksi kapabilitas

Ekstensi registrasi menerima largeBlob: { support: "preferred" } atau required. supported menunjukkan apakah kredensial yang dibuat dapat menyimpan blob; registrasi tidak menuliskan blob. Dengan required, authenticator yang tidak didukung akan dikecualikan, jadi ukur dampak kompatibilitasnya sebelum menjadikannya wajib.

3. Memisahkan pembacaan dan penulisan selama autentikasi

Autentikasi dapat meminta read: true atau menyediakan write; menyertakan keduanya akan gagal. Operasi tulis mewajibkan allowCredentials memuat tepat satu kredensial, dan keberhasilan dilaporkan melalui written. Anggota blob hanya ada setelah pembacaan berhasil, bukan hanya karena objek ekstensi tersebut ada.

4. Merancang privasi, pemulihan, dan fallback

Data authenticator bersifat buram, tidak dienkripsi secara otomatis oleh aplikasi. Klien dan server harus menyediakan enkripsi, pembuatan versi (versioning), dan pemeriksaan integritas. Jika kredensial tidak tersedia, perangkat tidak mendukung, kapasitas tidak mencukupi, atau pengguna menolak, gunakan salinan server. Catat log kapabilitas dan hasil, jangan pernah mencatat isi blob.

Contoh jawaban berkualitas tinggi

Saya tidak akan menggunakan largeBlob sebagai pengganti state sisi server. Fitur ini berguna untuk mengikat nilai buram berukuran kecil ke satu kredensial WebAuthn. Selama registrasi, saya akan meminta support: preferred dan memeriksa supported; selama autentikasi, saya akan memilih read atau write, menargetkan satu kredensial untuk penulisan, dan memeriksa blob atau written. Aplikasi bertanggung jawab atas enkripsi, versioning, dan integritas, sementara server menyimpan salinan yang dapat dipulihkan. Authenticator yang tidak didukung, batasan discoverable credential, kesalahan kapasitas, kegagalan tulis, dan pergantian perangkat semuanya akan fallback ke state server tanpa memblokir autentikasi. Saya hanya akan mewajibkan fitur ini jika produk menerima penurunan kompatibilitas dan memiliki rencana migrasi. Hal ini memanfaatkan penyimpanan authenticator tanpa membuat proses login atau pemulihan bergantung padanya.

Kesalahan umum

• Memperlakukan largeBlob sebagai IndexedDB, cookie, atau penyimpanan tersinkronisasi cloud tanpa batas.
• Menganggap blob dapat ditulis selama registrasi.
• Menyediakan read dan write secara bersamaan atau menyebutkan beberapa kredensial untuk operasi tulis.
• Hanya memeriksa keberadaan objek ekstensi alih-alih memeriksa supported, blob, atau written.
• Menulis data sensitif ke dalam blob buram tanpa enkripsi dari aplikasi.
• Memblokir login ketika authenticator tidak mendukung, alih-alih melakukan fallback ke server.

Pertanyaan lanjutan dan tanggapan

Bagaimana Anda memilih antara preferred versus required?

preferred mengizinkan authenticator yang tidak didukung dan menyediakan fallback; required mengecualikannya. Pilih preferred kecuali produk menerima cakupan yang lebih rendah dan benar-benar bergantung pada kapabilitas tersebut.

Mengapa operasi tulis harus menargetkan tepat satu kredensial?

Spesifikasi menggunakan target allowCredentials tunggal untuk mengidentifikasi kredensial yang sedang diperbarui. Beberapa kandidat akan menghasilkan kegagalan operasi yang tidak didukung (unsupported-operation failure), sehingga aplikasi harus menentukan kredensial pengguna terlebih dahulu.

Apa rencana migrasi perangkat?

Perlakukan blob sebagai cache atau salinan kunci opsional dan simpan materi pemulihan di server. Perangkat baru mendapatkan state server melalui registrasi ulang atau autentikasi; jangan berasumsi bahwa blob authenticator akan tersinkronisasi antarperangkat.