Temu duga Frontend: Bagaimanakah anda akan melancarkan WebAuthn conditional create secara selamat?

Gesaan dan konteks yang berkaitan

Produk ini sudah menyokong log masuk nama pengguna/kata laluan dan conditional get untuk log masuk passkey. Anda mahu menggunakan WebAuthn Level 3 conditional create selepas log masuk berkeyakinan tinggi, mencadangkan passkey tanpa mengganggu aliran. Terangkan pengesanan keupayaan penyemak imbas, pintu penciptaan (creation gates), pengesahan pelayan, sempadan privasi dan rollback.

Ini memberi tumpuan kepada platform Web dan UX pengesahan. Sokongan API penyemak imbas tidak bermakna peranti mempunyai pengesah (authenticator) yang boleh digunakan; penciptaan masih memerlukan persetujuan pengguna dan pengesahan pelayan.

Perkara yang dinilai oleh penemu duga

• Sama ada anda membezakan conditional create, conditional get dan penciptaan berasaskan butang yang eksplisit.
• Sama ada anda menghubungkan keupayaan, dasar, keadaan akaun dan penyegerakan rentas peranti ke dalam pintu yang jelas.
• Sama ada anda menghalang kelayakan pendua, salah ikatan akaun, kebocoran kewujudan kelayakan dan log masuk kata laluan yang disekat.
• Sama ada anda boleh melakukan pelancaran kenari (canary) dan menarik balik ciri tersebut daripada mendayakan API baharu di semua tempat.

Jawapan yang kukuh menganggap conditional create sebagai peningkatan berperingkat: percubaan yang tidak disokong, dibatalkan atau tamat masa membiarkan aliran utama tidak berubah, sementara pelayan masih mengesahkan challenge, origin, RP ID dan ikatan akaun.

Soalan penjelasan sebelum menjawab

1. Adakah sasarannya setiap pengguna yang log masuk, atau hanya pengguna dengan e-mel yang disahkan, MFA atau pengesahan semula berisiko tinggi baru-baru ini?
2. Adakah passkey yang disegerakkan berbilang peranti dibenarkan? Itu mengubah keperluan pemulihan dan pembatalan.
3. Bolehkah halaman tersebut sudah mempunyai permintaan credentials.create() yang belum selesai? Permintaan serentak menjadikan prom tidak dapat diramalkan.
4. Apabila conditional create tidak tersedia, patutkah anda menunjukkan butang eksplisit “Cipta passkey” atau menyembunyikan ciri tersebut?

Rangka kerja jawapan 30 saat

“Saya akan mengesan keupayaan conditional-create, kemudian menggabungkan keadaan akaun, kekuatan pengesahan baru-baru ini dan feature flag pelayan sebelum mencubanya. Klien memulakan paling banyak satu permintaan pada saat eksplisit yang diluluskan pengguna dan membatalkan pendua dengan AbortController; percubaan yang tidak disokong, dibatalkan atau tamat masa kembali kepada aliran asal. Pelayan mengikat challenge sekali guna kepada pengguna, origin, RP ID dan tamat tempoh, serta menyimpan kelayakan hanya selepas pengesahan. Semasa kenari, saya akan menjejaki kejayaan penciptaan, pembatalan, kelayakan pendua, sandaran kata laluan dan tiket pemulihan. Sesuatu insiden akan melumpuhkan flag; kelayakan sedia ada masih boleh digunakan atau dibatalkan secara berasingan.”

Jawapan mendalam langkah demi langkah

1. Asingkan dua interaksi bersyarat

Conditional get membolehkan pengguna memilih passkey sedia ada semasa memasukkan akaun; conditional create mencadangkan pendaftaran kelayakan baharu dalam konteks borang. Kedua-duanya bergantung pada keupayaan penyemak imbas dan pengesah, jadi sekadar menyemak objek PublicKeyCredential adalah tidak mencukupi.

Pengesanan keupayaan menentukan sama ada perlu mencuba, bukan sama ada perlu membenarkan. Pelayan masih harus mengikat pendaftaran kepada pengguna yang sedang disahkan dan merekodkan sumber penciptaan serta versi dasar.

2. Tentukan pintu penciptaan

Wajibkan semua yang berikut: penyemak imbas melaporkan keupayaan conditional-create; pengguna baru-baru ini menyelesaikan pengesahan yang mencukupi; akaun tidak berada dalam pemulihan, penggabungan atau perubahan berisiko tinggi; dan flag pelayan mendayakan penyewa serta bahagian trafik. Pada peranti baharu, terangkan faedahnya dan biarkan pengguna meneruskan daripada mencipta passkey semasa memuatkan halaman.

3. Cegah pendua dan keadaan perlumbaan (race conditions)

Benarkan satu permintaan cipta bagi setiap sesi halaman. Batalkan permintaan sebelumnya sebelum memulakan yang lain dan batalkannya apabila komponen dinyahlekap (unmount). Challenge pelayan adalah untuk kegunaan sekali sahaja, ID kelayakan mempunyai kekangan unik, dan penyerahan pendua mengembalikan hasil idempoten daripada mencipta baris lain.

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

4. Sahkan pendaftaran sepenuhnya

Pelayan mengesahkan challenge, origin, RP ID, tandatangan, user handle, dasar pengesahan (attestation policy) dan ID kelayakan. Jangan sekali-kali mempercayai hasil "dicipta" dari bahagian klien. Jika pengesahan peranti tidak diperlukan, pilih dasar pengesahan yang lebih mudah dan nyatakan pertukaran (trade-off) privasi dan risiko.

5. Kendalikan penyegerakan dan pemulihan

Passkey yang disegerakkan mungkin muncul selepas pengguna menukar peranti, tetapi penyegerakan bukanlah pemulihan akaun. Sediakan senarai kelayakan, pembatalan kelayakan tunggal dan laluan pemulihan untuk pengguna yang kehilangan setiap peranti. Jangan dedahkan kewujudan passkey kepada permintaan yang tidak disahkan.

6. Pelancaran kenari dengan telemetri yang berguna

Dayakan mengikut penyemak imbas, platform, penyewa dan tahap risiko. Rekodkan pengesanan keupayaan, paparan prom, persetujuan, kegagalan pengesahan, pembatalan/tamat masa, kelayakan pendua, sandaran kata laluan dan tiket sokongan. Asingkan “tidak disokong” daripada “ditolak pengguna”; jika tidak, anda tidak dapat mengetahui sama ada perlu menambah baik teks salinan atau melumpuhkan ciri tersebut.

7. Rollback tanpa merosakkan akaun

Gunakan flag jauh untuk menghentikan percubaan penciptaan baharu sambil mengekalkan log masuk passkey sedia ada. Jangan sekali-kali memadamkan kelayakan sebagai sebahagian daripada rollback keluaran; pembatalan ialah operasi akaun. Kekalkan tetingkap keserasian yang terhad untuk versi challenge yang lebih lama dan jalankan semula ujian penyemak imbas dan pengesah apabila tingkah laku berubah.

Contoh jawapan berkualiti tinggi

Saya akan melancarkan conditional create sebagai peningkatan yang boleh diterbalikkan. Klien mengesan keupayaan, kemudian menyemak keadaan akaun, kekuatan pengesahan baru-baru ini dan feature flag; satu permintaan bagi setiap halaman dikuatkuasakan dan AbortController membatalkan pendua. Pelayan mencipta challenge sekali guna dan mengesahkan challenge, origin, RP ID, tandatangan dan ID kelayakan sebelum penyimpanan kekal. Percubaan yang tidak disokong, dibatalkan atau tamat masa kembali kepada log masuk kata laluan dan tidak sekali-kali menjadi kegagalan log masuk. Saya akan melancarkan kenari mengikut platform dan risiko sambil menjejaki keupayaan, persetujuan, ralat pengesahan, kelayakan pendua, sandaran dan tiket pemulihan. Melumpuhkan flag akan menghentikan penciptaan baharu tetapi memastikan passkey sedia ada dan pembatalan kekal tersedia.

Kesilapan biasa

• Kesilapan → hanya menyemak sama ada PublicKeyCredential wujud → objek tersebut tidak membuktikan bahawa conditional create atau pengesah tersedia; pembetulan: gunakan pengesanan keupayaan dan kekalkan sandaran.
• Kesilapan → memanggil create secara senyap semasa memuatkan halaman → pengguna tidak memberi persetujuan dan prom pendua berkemungkinan berlaku; pembetulan: cetuskan pada saat berkeyakinan tinggi yang eksplisit dan biarkan pengguna meneruskan.
• Kesilapan → mempercayai hasil kejayaan dari bahagian klien → challenge, origin atau ikatan akaun mungkin belum disahkan; pembetulan: lengkapkan pengesahan pendaftaran pada pelayan.
• Kesilapan → memadamkan kelayakan baharu semasa rollback → rollback keluaran menjadi kemusnahan akaun; pembetulan: lumpuhkan penciptaan baharu dan uruskan pembatalan secara berasingan.

Soalan susulan dan respons

Patutkah anda memaparkan prom setiap hari selepas pengguna menolak?

Tidak. Rekodkan tempoh bertenang (cooldown) tempatan dan versi dasar. Tanya lagi hanya apabila risiko akaun, peranti atau keadaan produk berubah secara ketara; penolakan tidak boleh menjejaskan log masuk kata laluan.

Bagaimana jika akaun yang sama mempunyai dua baris dengan ID kelayakan yang sama?

Jadikan ID kelayakan unik, jadikan pendaftaran idempoten dan rekodkan sumbernya. Jika pendua sudah wujud, bekukan penulisan baharu dan gabungkan atau semak mengikut pengguna dan ID kelayakan; jangan sekali-kali menulis ganti secara senyap.

Keupayaan disokong tetapi kadar kejayaan tiba-tiba menurun. Apakah yang anda periksa dahulu?

Bahagikan mengikut versi penyemak imbas, platform, pengesah dan kod ralat untuk mengasingkan pembatalan, tamat masa, penolakan dasar dan kegagalan pengesahan pelayan. Jeda kohort flag yang terjejas, kekalkan log masuk kata laluan dan passkey sedia ada, betulkan puncanya dan sahkan semula dengan kohort kecil.