Penjelasan Teknis WebAuthn Conditional UI (Isi Otomatis Kunci Sandi)

Cheatsheet Passkeys. Panduan praktis, pola peluncuran, dan KPI untuk program passkeys.

Dapatkan cheat sheet

Dengan adopsi kunci sandi yang cepat (serta protokol WebAuthn yang mendasarinya), autentikasi telah menjadi lebih aman dan ramah pengguna bagi banyak orang. Salah satu kemajuan menonjol dari kunci sandi adalah integrasi Conditional UI, yang sering disebut sebagai "isi otomatis kunci sandi" atau Conditional Mediation (berikutnya kita akan tetap menggunakan istilah Conditional UI).

Terlepas dari perkenalannya yang baru-baru ini dan adopsinya yang terus berlanjut oleh browser, terdapat kesenjangan yang mencolok dalam dokumentasi teknis dan saran implementasi untuk Conditional UI. Artikel ini bertujuan untuk menjembatani kesenjangan tersebut dengan menjelaskan apa itu Conditional UI, bagaimana cara kerjanya, dan bagaimana mengatasi tantangan umum selama implementasinya.

Conditional UI mewakili mode baru untuk proses login kunci sandi / WebAuthn. Fitur ini secara selektif menampilkan kunci sandi dalam antarmuka pengguna (UI) hanya ketika seorang pengguna memiliki kredensial yang dapat ditemukan (resident key), yang merupakan jenis kunci sandi, terdaftar pada pihak pengandal (relying party - layanan online) yang disimpan di dalam autentikator sebuah perangkat (misalnya laptop, ponsel pintar). Kunci sandi tersebut ditampilkan dalam menu tarik-turun pilihan yang bercampur dengan kata sandi yang diisi secara otomatis, memberikan transisi yang mulus antara sistem kata sandi tradisional dan autentikasi kunci sandi tingkat lanjut, karena pengguna melihat keduanya dalam konteks yang sama. Pendekatan cerdas ini memastikan bahwa pengguna tidak kewalahan dengan pilihan yang tidak perlu dan dapat menavigasi proses login dengan lebih mulus.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

Pondasi dari Conditional UI dibangun di atas tiga pilar utama:

1. Menghargai Privasi Pengguna: Memastikan privasi pengguna dengan mencegah pengungkapan kredensial yang tersedia atau kurangnya persetujuan pengguna untuk mengungkap kredensial ini.
2. Pengalaman Pengguna yang Hebat Meskipun Tidak Ada Kunci Sandi: Memberdayakan pihak pengandal untuk mengimplementasikan WebAuthn secara oportunistik, memastikan pengalaman pengguna tetap baik bahkan jika kunci sandi tidak tersedia.
3. Transisi yang Mulus Dari Kata Sandi ke Kunci Sandi: Menggabungkan kunci sandi dengan autentikasi berbasis kata sandi untuk memuluskan transisi menuju metode autentikasi tanpa kata sandi (passwordless), memanfaatkan paradigma UX yang sudah dikenal pengguna.

• Autentikasi yang Disederhanakan: Prosesnya lebih disederhanakan dan efisien, menghilangkan kompleksitas yang sering kali terkait dengan berbagai metode autentikasi.
• Pengurangan Kesalahan Pengguna: Dengan hanya menyajikan opsi yang relevan, kemungkinan pengguna untuk melakukan kesalahan selama proses autentikasi menjadi lebih kecil.
• Peningkatan Kepuasan Pengguna: Menghapus langkah-langkah yang tidak perlu berarti pengguna dapat login dengan lebih cepat dan lebih mudah, yang mengarah pada peningkatan kepuasan pengguna.
• Integrasi Frontend yang Sederhana: Salah satu fitur menonjol dari Conditional UI adalah kemudahan integrasinya. Pengembang dapat dengan mulus menggabungkannya ke dalam frontend dengan beberapa baris kode (lihat di bawah).
• Login Tanpa Kata Sandi dan Tanpa Nama Pengguna: Salah satu manfaat besarnya adalah bahwa Conditional UI tidak hanya mempromosikan autentikasi tanpa kata sandi (passwordless) tetapi juga pengalaman tanpa nama pengguna atau tanpa akun. Pengguna terbebas dari beban mental untuk mengingat alamat email tertentu atau handle pengguna mereka dari saat pendaftaran. Sebaliknya, mereka dapat mengandalkan saran dari browser, yang mencakup alamat email/handle pengguna yang dipasangkan dengan kunci sandi yang sesuai dalam menu isi otomatis.
• Menyelesaikan Dilema Bootstrapping: Transisi dari sistem nama pengguna-kata sandi tradisional ke kunci sandi bisa jadi menakutkan. Conditional UI mengatasi tantangan transisi ini. Situs web dapat menginisiasi panggilan kunci sandi / WebAuthn di samping prompt kata sandi konvensional tanpa khawatir tentang potensi kesalahan dialog modal jika perangkat tidak memiliki kredensial yang dibutuhkan.

Berlangganan Passkeys Substack kami untuk berita terbaru.

Berlangganan

• Kurva Pembelajaran bagi Pengembang: Conditional UI memperkenalkan paradigma baru, yang berarti ada kurva pembelajaran yang terlibat bagi pengembang yang tidak familier dengan kerumitannya.
• Ketergantungan Perangkat / Browser: Keberhasilan Conditional UI bergantung pada perangkat pengguna atau kompatibilitas browser. Mengingat bahwa saat ini tidak semua browser atau perangkat mendukungnya, hal ini dapat membatasi penerapannya.
• Pengelola Kata Sandi Menonaktifkan Autocomplete: Beberapa pengelola kata sandi modern dan ekstensi browser mereka memodifikasi DOM situs web dan menonaktifkan atau menimpa tag autocomplete di bidang input untuk mendukung fitur autocomplete mereka sendiri. Ini dapat menyebabkan pengalaman pengguna yang tidak konsisten dan tidak memuaskan. Mengingat standar untuk Conditional UI masih relatif baru, kami berharap segalanya membaik, sehingga misalnya tidak ada dua menu isi otomatis yang tumpang tindih atau menu yang diinginkan tidak ditampilkan sama sekali.

Berikut ini, kami memberikan rincian langkah demi langkah dari setiap langkah dalam keseluruhan alur Conditional UI:

Secara umum, alur proses Conditional UI dapat dibagi menjadi dua fase. Selama fase pemuatan halaman (page load), logika Conditional UI terjadi di latar belakang, sedangkan di fase operasi pengguna, pengguna harus secara aktif melakukan sesuatu.

1. Pemeriksaan Ketersediaan Conditional UI: Klien (browser) memanggil fungsi isConditionalMediationAvailable() untuk mendeteksi apakah kombinasi browser / perangkat saat ini mendukung Conditional UI. Hanya jika responsnya adalah true, proses berlanjut, jika tidak, proses Conditional UI dibatalkan.
2. Memanggil Endpoint Conditional UI: Selanjutnya, klien memanggil endpoint Conditional UI milik server untuk mengambil PublicKeyCredentialRequestOptions.
3. Menerima PublicKeyCredentialRequestOptions: Server mengembalikan PublicKeyCredentialRequestOptions yang berisi challenge dan lebih banyak opsi server WebAuthn (misalnya allowCredentials, extensions, userVerification).
4. Memulai Autentikasi Lokal: Dengan memanggil credentials.get() beserta PublicKeyCredentialRequestOptions yang diterima dan properti mediation yang diatur menjadi conditional, proses untuk autentikasi lokal pada perangkat akan dimulai.
5. Menampilkan Pilihan Isi Otomatis: Menu isi otomatis untuk kunci sandi muncul. Penataan gaya (styling) tertentu bergantung pada browser dan perangkat (misalnya beberapa mengharuskan pengguna untuk menempatkan kursor di bidang input, beberapa secara otomatis menampilkan menu saat pemuatan halaman, lihat di bawah).
6. Autentikasi Pengguna Lokal: Pengguna memilih kunci sandi dari menu isi otomatis yang ingin mereka gunakan dan mengautentikasi melalui dialog autentikasi perangkat mereka (misalnya melalui Face ID, Touch ID, Windows Hello).
7. Mengirim Respons Autentikator ke Server: Jika autentikasi pengguna lokal berhasil, respons autentikator dikirim kembali ke server.
8. Pengguna Berhasil Login dan Diarahkan Ulang: Setelah server menerima respons autentikator, server memvalidasi tanda tangan tersebut terhadap kunci publik akun pengguna yang sesuai dalam database. Jika verifikasi berhasil, pengguna diberikan akses, berhasil login, dan diarahkan ulang ke halaman akun.

Dengan mengikuti alur proses ini, Conditional UI menawarkan pengalaman autentikasi yang mulus dan ramah pengguna.

Untuk membuat Conditional UI bekerja, beberapa aspek umum perlu dipertimbangkan:

• Spesifikasi Kredensial: Conditional UI secara khusus dirancang untuk beroperasi hanya dengan resident keys / discoverable credentials. Alasannya adalah autentikator tidak menyimpan data spesifik pengguna (misalnya, nama, nama tampilan) untuk non-resident keys / non-discoverable credentials. Akibatnya, menggunakan jenis kunci ini untuk isi otomatis kunci sandi tidak dimungkinkan.
• Penyaringan Kredensial: Fitur allowCredentials tetap didukung, memfasilitasi situs web yang telah mengetahui identitas pengguna (misalnya, jika nama pengguna dikirim dalam panggilan mediasi awal karena nama tersebut mungkin disimpan di LocalStorage browser) untuk mempersempit daftar kredensial yang ditampilkan kepada pengguna selama isi otomatis.

Bergabunglah dengan komunitas passkeys kami untuk update dan dukungan.

Gabung

Untuk membuat Conditional UI bekerja di sisi klien, persyaratan berikut harus terpenuhi:

• Browser yang Kompatibel: Pastikan bahwa pengguna menggunakan browser modern yang mendukung Conditional UI (lihat di sini untuk cakupan browser terbaru).
• JavaScript Diaktifkan: JavaScript harus diaktifkan untuk memfasilitasi operasi Conditional UI.
• Uji Ketersediaan Conditional UI: Pihak pengandal (sisi server) harus memiliki kepastian bahwa Conditional UI tersedia di sisi klien, ketika menerima panggilan mediasi WebAuthn agar menghindari memicu adanya kesalahan yang terlihat oleh pengguna dalam skenario di mana Conditional UI tidak didukung. Untuk mengatasi ini, disarankan untuk menggunakan metode isConditionalMediationAvailable() dan memeriksa ketersediaan teknis dari Conditional UI (lihat di bawah untuk detail lebih lanjut).
• Diperlukan Bidang Input HTML: Agar Conditional UI dapat berfungsi, Anda perlu memiliki bidang input HTML di halaman web Anda. Jika Anda tidak memilikinya, Anda perlu memberikan dukungan untuk proses login kunci sandi / WebAuthn biasa yang dipicu dengan interaksi pengguna, seperti klik tombol.
• Menghapus Protokol Batas Waktu (Timeout): Parameter batas waktu (misalnya, pengguna membutuhkan waktu yang sangat lama untuk memutuskan kunci sandi di menu isi otomatis) harus diabaikan dalam penyiapan ini.

Untuk membuat Conditional UI bekerja, beberapa persyaratan di sisi server juga harus terpenuhi:

• Menjalankan Server WebAuthn: Karena kita masih berada dalam konteks kunci sandi / WebAuthn, diperlukan sebuah server WebAuthn yang berjalan yang mengelola prosedur autentikasi.
• Menyediakan Endpoint Awal Mediasi: Dibandingkan dengan endpoint login WebAuthn biasa, ada baiknya menyediakan endpoint lain yang memiliki fungsionalitas serupa tetapi dapat menangani handle pengguna opsional (misalnya, alamat email, nomor telepon, nama pengguna).

Sejak peluncuran resmi Conditional UI pada akhir tahun 2022 dan versi beta sebelumnya, kami telah menguji dan bekerja secara ekstensif dengannya. Berikut ini, kami ingin membagikan kepada Anda tips praktis yang membantu selama implementasi Conditional UI.

Eksperimen dengan alur passkey di Passkeys Debugger.

Coba gratis

Contoh kode minimalis lengkap untuk metode Conditional UI akan terlihat seperti ini:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // retrieve the request options (incl. the challenge) from the WebAuthn server
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

Implementasikan deteksi Conditional UI yang memastikan bahwa Conditional UI hanya digunakan ketika kombinasi perangkat / browser saat ini mendukungnya. Hal ini harus berjalan tanpa menyajikan kesalahan yang terlihat oleh pengguna jika tidak ada dukungan Conditional UI. Memasukkan metode isConditionalMediationAvailable() di dalam antarmuka pengguna mengatasi masalah ini. Jika dukungan Conditional UI ada, proses login Conditional UI dapat dimulai.

// source: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples
 
// Availability of `window.PublicKeyCredential` means WebAuthn is usable.
if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) {
    // Check if conditional mediation is available.
    const isCMA = await PublicKeyCredential.isConditionalMediationAvailable();
    if (isCMA) {
        // Call WebAuthn authentication start endpoint
 
        let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
        const credential = await navigator.credentials.get({
            publicKey: options.publicKeyCredentialRequestOptions,
            mediation: "conditional",
        });
        /*
        ...
        */
    }
}

Bidang input harus menerima token autofill HTML webauthn. Ini memberi sinyal kepada klien untuk mengisi kunci sandi ke permintaan yang sedang berlangsung. Selain kunci sandi, nilai isi otomatis lainnya mungkin juga ditampilkan. Token isi otomatis ini dapat dipasangkan dengan token lain yang ada, misalnya:

• autocomplete="username webauthn": Selain menampilkan kunci sandi, token ini juga menyarankan isi otomatis nama pengguna.
• autocomplete="current-password webauthn": Selain menampilkan kunci sandi, token ini lebih lanjut meminta untuk isi otomatis kata sandi.

<label for="name">Username:</label>
<input type="text" name="name" autocomplete="username webauthn" />
<label for="password">Password:</label>
<input type="password" name="password" autocomplete="current-password webauthn" />

Untuk detail lebih lanjut, kami sarankan untuk membaca posting blog kami yang memberikan lebih banyak detail tentang token autofill / autocomplete untuk kunci sandi dan kata sandi.

Untuk mengambil kunci sandi yang tersedia setelah menerima objek PublicKeyCredentialRequestOptions, fungsi navigator.credentials.get() harus dipanggil (yang melayani kunci sandi maupun kata sandi). Objek PublicKeyCredentialRequestOptions perlu memiliki parameter mediation yang disetel ke conditional untuk mengaktifkan Conditional UI pada klien. Untuk kasus di mana Anda menginginkan prompt kunci sandi modal sebagai gantinya, lihat mediasi langsung.

const credential = await navigator.credentials.get({
    publicKey: options.publicKeyCredentialRequestOptions,
    mediation: "conditional",
});

Jika tidak ada kunci sandi yang tersedia, atau pengguna mengabaikan kunci sandi yang disarankan dan memasukkan email mereka, alur Conditional UI akan dihentikan. Hal ini menggarisbawahi pentingnya selalu mendukung login standar kunci sandi / WebAuthn melalui sebuah modal.

Satu poin penting yang harus ditekankan di sini adalah potensi kebutuhan untuk menghentikan permintaan Conditional UI yang sedang berlangsung. Berlawanan dengan pengalaman modal, menu tarik-turun isi otomatis tidak memiliki tombol pembatalan. Sesuai desain WebAuthn, hanya satu permintaan kredensial aktif tunggal yang harus diproses pada satu waktu tertentu. Standar WebAuthn menyarankan untuk menggunakan sebuah AbortController untuk membatalkan sebuah proses WebAuthn, yang berlaku untuk proses login reguler dan Conditional UI (lihat di sini untuk detail).

Dalam telemetri produksi, jalur pembatalan ini sering kali merupakan hasil alur kontrol yang diharapkan, bukan kegagalan sistem. Jika Anda melihat volume kesalahan yang tinggi, Anda perlu mengklasifikasikan kasus yang diharapkan vs yang tidak diharapkan berdasarkan tipe operasi dan waktu (timing) sebelum memperlakukannya sebagai regresi (lihat Kesalahan WebAuthn).

Proses login Conditional UI menjadi aktif segera setelah pengguna tiba di halaman tersebut. Tugas awal haruslah membuat objek AbortController dengan cakupan global. Ini akan bertindak sebagai sinyal bagi klien Anda untuk mengakhiri permintaan isi otomatis, terutama jika pengguna memutuskan untuk melakukan proses login kunci sandi reguler. Pastikan bahwa AbortController dapat diaktifkan oleh fungsi lain dan diatur ulang jika proses Conditional UI harus dimulai ulang. Gunakan properti signal di dalam pemanggilan navigator.credentials.get(), menggabungkan sinyal AbortController Anda sebagai nilainya. Hal ini memberi sinyal kepada fungsi kunci sandi / WebAuthn bahwa permintaan tersebut harus dihentikan jika sinyal dibatalkan. Ingatlah untuk menyiapkan AbortController yang baru setiap kali Anda memicu Conditional UI. Menggunakan AbortController yang sudah dibatalkan akan menyebabkan pembatalan instan pada fungsi kunci sandi / WebAuthn. Langkah-langkah selanjutnya sejajar dengan proses login kunci sandi reguler. Berikut ini, Anda melihat contoh kode dari langkah-langkah yang disebutkan di atas:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // retrieve the request options (incl. the challenge) from the WebAuthn server
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

Apabila Conditional UI tidak didukung, arahkan pengguna menuju proses login kunci sandi reguler. Menawarkan jalur ini penting bagi pengguna yang bergantung pada kunci keamanan perangkat keras (misalnya YubiKey) atau mereka yang terpaksa menggunakan non-resident keys / non-discoverable credentials karena keterbatasan autentikator.

Lihat berapa banyak orang yang benar-benar memakai passkeys.

Lihat data adopsi

Saat Anda mengembangkan aplikasi native, misalnya untuk iOS atau Android, Conditional UI juga bisa berfungsi. Tidak peduli apakah Anda mengimplementasikannya secara native di Flutter, Kotlin, atau Swift, atau jika Anda memutuskan untuk menggunakan Chrome Custom Tabs (CCT) atau SFSafariViewController atau SFAuthenticationSession / ASWebAuthenticationSession. Kedua pendekatan mendukung Conditional UI.

Secara umum, kami hampir tidak menemukan dokumentasi mengenai cara mengimplementasikan dukungan Conditional UI untuk aplikasi iOS. Namun, selama penelitian kami, kami menemukan dua cara untuk menambahkan dukungan Conditional UI pada aplikasi iOS, karena pengalaman pengguna juga akan berbeda.

Tipe A: Overlay / Popup yang Menutupi Hampir Seluruh Layar

Tipe pertama, tipe A, menampilkan overlay / popup yang membentang hampir ke seluruh layar. Di sini, Anda akan melihat semua kunci sandi yang tersedia untuk pihak pengandal ini. Contoh terkemuka yang mengimplementasikan Conditional UI dengan cara ini adalah KAYAK. Overlay / popup muncul secara otomatis, ketika pengguna membuka layar yang benar.

Tipe B: Isi Otomatis Keyboard

Tipe kedua, tipe B, menampilkan kunci sandi yang cocok di bagian isi otomatis keyboard (tempat kata sandi juga disarankan untuk diisi otomatis). Mengklik nilai yang disarankan akan melakukan autentikasi Face ID dan memungkinkan Anda masuk. Dalam versi aplikasi iOS panel developer Corbado saat ini, kami telah mengimplementasikannya dengan cara ini (lihat pesan Masuk dengan kunci sandi untuk <relying party ID> bersama dengan nama pengguna WebAuthn). Untuk dapat muncul, pengguna harus mengetuk ke dalam bidang input:

Fitur isi otomatis kunci sandi di bagian keyboard ini mungkin bermasalah saat iOS baru saja diinstal ulang karena rupanya ada semacam caching di latar belakang yang mencari semua kunci sandi yang tersedia untuk pihak pengandal ini.

Mengklik ikon kunci di sebelah kanan kunci sandi yang disarankan akan mengarah ke situs umum untuk memilih kata sandi / kunci sandi di iOS:

Harap diperhatikan bahwa kami belum menemukan dokumentasi resmi, dan wawasan kami didasarkan pada pengalaman dan hipotesis kami, bukan pada bukti nyata dari implementasi yang tepat.

Di Android, cerita tentang Conditional UI sedikit lebih jelas, karena hanya ada satu tipe untuk Conditional UI / isi otomatis kunci sandi yang memanfaatkan Android Credential Manager API (lihat dokumentasinya di sini). Karena penyedia layanan Android dapat berbeda-beda, pantau kesalahan kunci sandi Credential Manager secara terpisah dari pola kegagalan WebAuthn khusus browser.

Membuka halaman di mana Conditional UI diimplementasikan akan menampilkan layar berikut, di mana Anda akan menemukan berbagai cara untuk masuk:

Mengklik Lebih banyak rincian masuk tersimpan (More saved sign-ins) memberikan opsi lain untuk dipilih guna login (termasuk autentikasi lintas perangkat dan pemilihan platform sinkronisasi kunci sandi yang berbeda, misalnya Samsung Pass atau 1Password):

Untuk mengilustrasikan bagaimana tampilan Conditional UI bagi pengguna akhir, kami menambahkan beberapa tangkapan layar dari menu isi otomatis Conditional UI yang menggunakan https://passkeys.eu.

Coba passkeys dalam demo live.

Coba passkeys

Mari kita lihat beberapa skenario umum pada aplikasi kehidupan nyata.

Jika tidak ada kunci sandi yang tersimpan untuk sebuah situs, Conditional UI akan berperilaku berbeda tergantung pada browser dan OS.

Pada Chrome di macOS, mengklik bidang input akan menampilkan menu tarik-turun isi otomatis yang kosong:

Pada Safari di macOS, tidak ada menu tarik-turun yang ditampilkan - hanya ikon halus di bidang input:

Pada Android atau iOS, antarmuka isi otomatis hanya muncul jika pengguna mengetuk bidang input dan OS menemukan kredensial yang cocok.

Variabilitas ini disengaja dan merupakan bagian dari model privasi WebAuthn: situs web tidak dapat mendeteksi apakah pengguna memiliki kunci sandi, kecuali pengguna tersebut memilihnya secara aktif.

Jika pengguna telah memasang beberapa penyedia kunci sandi (misalnya iCloud Keychain, Google Password Manager, 1Password), browser atau OS akan biasanya mengambil default ke pengelola kredensial utama pengguna.

Untuk daftar berbagai penyedia kunci sandi / pengelola kredensial yang mendukung kunci sandi, kami sarankan untuk melihat tautan GitHub berikut.

Di Android, Credential Manager mengekspos berbagai penyedia layanan seperti Samsung Pass atau 1Password.

1. Saat mengklik pada bidang input pengidentifikasi pengguna, menu ini muncul di mana pengguna dapat memilih sebuah kunci sandi.

2. Jika pengguna mengklik "Lebih banyak kunci sandi (More passkeys)" di layar sebelumnya, prakondisi dari penyedia kunci sandi lain / pengelola kredensial dan kunci sandi akan muncul:

3. Jika pengguna mengklik "Lebih banyak rincian masuk tersimpan (More saved sign-ins)" di layar sebelumnya, sebuah daftar keseluruhan akan muncul tempat pengguna dapat memilih kunci sandi.

Pada iOS, ikon kunci membuka daftar lengkap kunci sandi dari berbagai sumber.

1. Pada awalnya, di iOS 18+, Conditional UI reguler dengan penyedia kunci sandi default akan muncul.

2. Saat mengklik ikon keyboard, menu pemilihan berikut muncul.

3. Setelah memilih pengelola kredensial / penyedia kunci sandi, pengguna dapat memilih kunci sandi yang akan digunakan.

Kunci sandi (passkeys), dengan kemampuan Conditional UI / isi otomatis kunci sandinya, merupakan cara baru untuk melakukan autentikasi online. Ketika kita beralih ke era di mana kata sandi semakin banyak digantikan oleh kunci sandi, kebutuhan akan mekanisme transisi yang kuat dan ramah pengguna tidak dapat disangkal. Artikel ini telah membantu memahami cara mengimplementasikan Conditional UI dengan benar, sebuah bantuan besar dalam proses transisi, dan aspek mana saja yang perlu diberi perhatian khusus.

Tentang Corbado

Corbado adalah Authentication Intelligence Platform untuk tim CIAM yang menjalankan autentikasi consumer dalam skala besar. Kami membantu Anda melihat apa yang tidak bisa ditunjukkan oleh log IDP dan tool analytics generik: device, versi OS, browser, dan credential manager mana yang mendukung passkey; mengapa enrollment tidak menjadi login; di mana flow WebAuthn gagal; dan kapan update OS atau browser diam-diam merusak login — semuanya tanpa mengganti Okta, Auth0, Ping, Cognito, atau IDP internal Anda. Dua produk: Corbado Observe menambah observability untuk passkey dan metode login lainnya. Corbado Connect menghadirkan managed passkey dengan analytics terintegrasi (berdampingan dengan IDP Anda). VicRoads menjalankan passkey untuk 5M+ pengguna dengan Corbado (aktivasi passkey +80%). Bicara dengan pakar Passkey →

Panggil PublicKeyCredential.isConditionalMediationAvailable() dan lanjutkan hanya jika itu mengembalikan true. Pemeriksaan ini mencegah kesalahan yang terlihat oleh pengguna pada kombinasi browser dan perangkat yang tidak didukung. Metode ini harus dievaluasi pada setiap pemuatan halaman sebelum memanggil navigator.credentials.get() dengan mediation: "conditional".

Autentikator hanya menyimpan data spesifik pengguna seperti nama dan nama tampilan untuk resident keys (kredensial yang dapat ditemukan). Non-resident keys tidak mempertahankan informasi ini, sehingga menu isi otomatis tidak dapat mengisi detail akun untuk dipilih oleh pengguna.

Perilakunya bervariasi berdasarkan platform. Chrome pada macOS menunjukkan menu isi otomatis tarik-turun yang kosong, Safari pada macOS hanya menampilkan ikon halus pada bidang input, dan pada Android atau iOS antarmuka isi otomatis hanya muncul jika OS menemukan kredensial yang cocok setelah pengguna mengetuk bidang input. Variabilitas ini disengaja dan merupakan bagian dari model privasi WebAuthn: situs web tidak dapat mendeteksi apakah ada kunci sandi kecuali pengguna secara aktif memilihnya.

Buat sebuah AbortController dengan cakupan global dan lewati signal miliknya ke navigator.credentials.get(). Panggil .abort() pada controller saat pengguna memulai alur login modal. Selalu buat instansiasi (instantiate) AbortController yang baru setiap kali Conditional UI dimulai ulang, karena menggunakan ulang controller yang sudah dibatalkan menyebabkan pembatalan segera dari permintaan WebAuthn tersebut.

Conditional UI berfungsi pada aplikasi native iOS maupun Android. iOS mendukung dua varian: popup overlay layar penuh dan saran isi otomatis di keyboard. Android menggunakan Credential Manager API, yang dapat memunculkan kunci sandi dari beberapa penyedia layanan seperti Samsung Pass atau 1Password.