Temu duga Frontend: Bolehkah WebAuthn largeBlob menggantikan keadaan pengguna bahagian pelayan?

Gesaan dan skop

Produk ingin mengikat konfigurasi kecil yang disulitkan pada kelayakan WebAuthn pengguna untuk mengurangkan keadaan bahagian pelayan (server-side state). Terangkan bila largeBlob sesuai, perbezaan antara pendaftaran dan pengesahan, cara klien menyemak hasil, serta cara log masuk dan ketepatan data bertahan pada peranti yang tidak disokong.

Perkara yang diuji oleh penemu duga

• Sama ada anda mengetahui bahawa largeBlob ialah data legap (opaque data) yang dikaitkan dengan satu kelayakan, bukan storan klien umum.
• Sama ada anda membezakan input dan output pendaftaran support daripada pengesahan read dan write.
• Sama ada anda mengambil kira kapasiti pengesah (authenticator), discoverable credentials, dan kekangan penulisan satu kelayakan.
• Sama ada anda mereka bentuk pengesanan keupayaan, sandaran pelayan, privasi dan sandaran kegagalan (fallback).

Soalan penjelasan

1. Adakah data mesti dibawa bersama kelayakan ini, atau adakah pangkalan data pelayan dan IndexedDB sudah mencukupi?
2. Apakah keperluan saiz, kerahsiaan, kebolehpulihan dan rentas peranti?
3. Adakah authenticator sasaran menyokong largeBlob, dan adakah kelayakan tersebut discoverable?
4. Bagaimanakah sistem pulih selepas penulisan gagal, kelayakan hilang atau pertukaran peranti berlaku?

Jawapan 30 saat

Saya akan menganggap largeBlob sebagai keupayaan authenticator pilihan, bukan storan utama. Semasa pendaftaran, minta support: preferred dan periksa supported; semasa pengesahan, gunakan sama ada read atau write, sasar tepat satu kelayakan untuk penulisan, dan periksa blob atau written. Sulitkan dan hadkan saiz data serta simpan salinan pelayan yang boleh dipulihkan. Keupayaan yang tidak disokong, had kapasiti, atau kegagalan penulisan hendaklah beralih kepada keadaan pelayan tanpa menyekat log masuk atau menganggap penulisan yang tidak disahkan sebagai berjaya.

Reka bentuk langkah demi langkah

1. Pilih sempadan data yang betul

Spesifikasi mentakrifkan largeBlob sebagai data legap yang dikaitkan dengan sesuatu kelayakan. Ia sesuai untuk konfigurasi kecil yang terikat dengan kelayakan atau bahan kunci, bukan profil pengguna, penyegerakan rentas kelayakan, atau pangkalan data objek. Authenticator mempunyai kapasiti terhad, jadi pelayan harus mengekalkan maklumat pemulihan.

2. Gunakan pendaftaran hanya untuk pengesanan keupayaan

Sambungan pendaftaran menerima largeBlob: { support: "preferred" } atau required. supported menyatakan sama ada kelayakan yang dicipta boleh menyimpan blob; pendaftaran tidak menulis blob. Dengan required, authenticator yang tidak disokong dikecualikan, jadi ukur kos keserasian sebelum menjadikannya mandatori.

3. Asingkan pembacaan dan penulisan semasa pengesahan

Pengesahan boleh meminta read: true atau menyediakan write; membekalkan kedua-duanya akan gagal. Penulisan memerlukan allowCredentials mengandungi tepat satu kelayakan, dan kejayaan dilaporkan oleh written. Anggota blob hadir hanya selepas pembacaan yang berjaya, bukan semata-mata kerana objek sambungan wujud.

4. Reka bentuk privasi, pemulihan dan fallback

Data authenticator adalah legap, tidak disulitkan secara automatik oleh aplikasi. Klien dan pelayan harus menyediakan penyulitan, pemversian (versioning) dan semakan integriti. Jika kelayakan tidak tersedia, peranti tidak menyokong, kapasiti tidak mencukupi, atau pengguna menolak, gunakan salinan pelayan. Log keupayaan dan hasil, jangan sesekali log kandungan blob.

Model jawapan berkualiti tinggi

Saya tidak akan menggunakan largeBlob sebagai pengganti keadaan bahagian pelayan. Ia berguna untuk mengikat nilai legap yang kecil pada satu kelayakan WebAuthn. Semasa pendaftaran saya akan meminta support: preferred dan memeriksa supported; semasa pengesahan saya akan memilih read atau write, menyasarkan satu kelayakan untuk penulisan, dan memeriksa blob atau written. Aplikasi mengendalikan penyulitan, pemversian dan integriti, manakala pelayan menyimpan salinan yang boleh dipulihkan. Authenticator yang tidak disokong, kekangan discoverable-credential, ralat kapasiti, kegagalan penulisan dan pertukaran peranti semuanya beralih kepada keadaan pelayan tanpa menyekat pengesahan. Saya hanya akan mewajibkan ciri ini apabila produk menerima liputan keserasian yang berkurangan dan mempunyai pelan migrasi. Ini memanfaatkan storan authenticator tanpa menjadikan log masuk atau pemulihan bergantung sepenuhnya padanya.

Kesilapan biasa

• Menganggap largeBlob sebagai IndexedDB, kuki, atau storan awan tanpa had yang disegerakkan.
• Menganggap blob boleh ditulis semasa pendaftaran.
• Membekalkan read dan write bersama-sama atau menamakan berbilang kelayakan untuk penulisan.
• Hanya menyemak kewujudan objek sambungan dan bukannya menyemak supported, blob, atau written.
• Menulis data sensitif ke dalam blob legap tanpa penyulitan aplikasi.
• Menyekat log masuk apabila authenticator tiada sokongan dan bukannya beralih ke sandaran pelayan.

Soalan susulan dan respons

Bagaimanakah anda memilih antara preferred berbanding required?

preferred membenarkan authenticator yang tidak disokong dan peralihan fallback; required mengecualikannya. Utamakan preferred melainkan produk menerima liputan yang lebih rendah dan benar-benar bergantung pada keupayaan tersebut.

Mengapakah penulisan mesti menyasarkan tepat satu kelayakan?

Spesifikasi menggunakan sasaran allowCredentials tunggal untuk mengenal pasti kelayakan yang sedang dikemas kini. Berbilang calon akan menghasilkan kegagalan operasi yang tidak disokong (unsupported-operation failure), jadi aplikasi mesti menyelesaikan kelayakan pengguna terlebih dahulu.

Apakah pelan migrasi peranti?

Anggap blob sebagai cache pilihan atau salinan kunci dan simpan bahan pemulihan pada pelayan. Peranti baharu memperoleh keadaan pelayan melalui pendaftaran semula atau pengesahan; jangan menganggap blob authenticator disegerakkan merentas peranti.