Kapabilitas Client WebAuthn

Looking for a dev-focused passkey reference? Download our Passkeys Cheat Sheet. Trusted by dev teams at Ally, Stanford CS & more.

Get Cheat Sheet

WebAuthn adalah standar modern di balik passkey. Alih-alih mengandalkan password tradisional, standar ini memanfaatkan kriptografi kunci publik, memungkinkan pengguna untuk melakukan autentikasi dengan passkey, yang dapat mencakup biometrik (seperti sidik jari atau pengenalan wajah) atau kunci keamanan fisik. Pergeseran ini tidak hanya meningkatkan keamanan tetapi juga menyempurnakan pengalaman pengguna dengan menghilangkan kebutuhan manajemen password.

Standar WebAuthn Level 3 memperkenalkan kapabilitas client baru (yang bisa diambil melalui API browser getClientCapabilities()), yang bertujuan untuk memberikan developer dan platform lebih banyak kontrol dan fleksibilitas saat mengimplementasikan passkey. Pembaruan ini membawa peningkatan yang menyederhanakan proses integrasi passkey di berbagai perangkat, browser, dan platform, guna memastikan perjalanan pengguna yang lebih mulus dan konsisten.

Di artikel blog ini, kita akan menjawab pertanyaan-pertanyaan berikut:

1. Apa itu kapabilitas client WebAuthn?
2. Apa saja kapabilitas client WebAuthn yang ada?
3. Bagaimana kapabilitas client WebAuthn meningkatkan implementasi passkey?
4. Mengapa kapabilitas client WebAuthn penting bagi developer maupun product manager?

Pada akhirnya, kita akan memahami bagaimana fitur-fitur ini bisa membantu kita membuat alur autentikasi yang mulus, aman, dan sejalan dengan ekspektasi pengguna modern.

Kapabilitas client WebAuthn adalah sekumpulan fitur yang memungkinkan browser dan platform mengomunikasikan jenis fungsionalitas WebAuthn yang mereka dukung. Singkatnya, mereka bertindak seperti "daftar periksa fitur" yang memberi tahu website metode autentikasi dan pengaturan apa saja yang tersedia di perangkat pengguna. Hal ini memungkinkan developer menyesuaikan alur autentikasi berdasarkan kapabilitas client, memastikan pengalaman pengguna yang lebih mulus dan aman.

Misalnya, jika browser memberikan sinyal bahwa ia mendukung autentikasi biometrik (seperti Touch ID), developer bisa merancang alur login mereka untuk menawarkan opsi login dengan sidik jari kepada pengguna. Sebaliknya, jika browser tidak mendukung fitur tertentu, developer bisa memberikan opsi alternatif, seperti password atau SMS OTP. Dalam praktiknya, jalur kapabilitas yang tidak didukung atau terputus masih bisa muncul sebagai kegagalan browser secara umum, sehingga tim sebaiknya memetakan hasil ini ke klasifikasi error WebAuthn yang eksplisit.

Standar WebAuthn Level 3 memperkenalkan beberapa kapabilitas client baru yang membuat implementasi passkey menjadi lebih fleksibel dan ramah pengguna. Dukungan pertama untuk pemanggilan API getClientCapabilities() diperkenalkan di Safari 17.4.

Untuk mendeteksi dukungan di browser, snippet berikut ini bisa sangat berguna:

// Check if PublicKeyCredential is supported in the current browser
if (typeof PublicKeyCredential === "undefined") {
    console.log("PublicKeyCredential is not supported in this browser.");
}
 
// Check if getClientCapabilities method exists on PublicKeyCredential
if (typeof PublicKeyCredential.getClientCapabilities === "function") {
    try {
        let capabilities = await PublicKeyCredential.getClientCapabilities();
        console.log(capabilities);
    } catch (error) {
        console.error("Error getting client capabilities:", error);
    }
} else {
    console.log("getClientCapabilities is not supported in this browser");
}

getClientCapabilities() memungkinkan website dan aplikasi untuk meminta client (misalnya, browser atau perangkat) untuk menentukan fitur WebAuthn mana yang didukungnya. Dengan memahami kapabilitas client, developer bisa mengoptimalkan alur autentikasi untuk memanfaatkan fitur yang tersedia, seperti autentikasi biometrik, dan menyediakan metode alternatif jika kapabilitas tertentu tidak ada.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Berikut adalah pandangan lebih dekat mengenai kapabilitas client WebAuthn dan dampaknya terhadap integrasi passkey:

conditionalCreate memungkinkan pembuatan passkey otomatis berdasarkan kondisi tertentu. Sebuah aplikasi mungkin menggunakan kapabilitas ini untuk membuat passkey secara otomatis selama autofill password jika password manager memiliki dukungan yang sesuai. Fitur ini membantu mendorong adopsi passkey dan penggunaan selanjutnya dengan mentransisikan pengguna dari password ke passkey secara otomatis.

Mirip dengan conditionalCreate, conditionalGet memicu login passkey secara otomatis. Ini berguna dalam skenario di mana UX passkey terbaik harus diaktifkan, membuat login tidak hanya tanpa password (passwordless) tetapi juga tanpa username (usernameless) — pengguna cukup mengeklik passkey yang dipilih di modal/dropdown dan bisa langsung melakukan autentikasi. Dengan menggunakan kapabilitas ini, developer bisa memastikan autentikasi passkey hanya terjadi saat yang tepat, meminimalkan prompt yang tidak perlu dan menyempurnakan pengalaman pengguna.

hybridTransport memastikan bahwa passkey bisa digunakan di berbagai perangkat, memungkinkan autentikasi lintas perangkat yang mulus (melalui kode QR dan Bluetooth). Misalnya, pengguna bisa menggunakan passkey yang tersimpan di smartphone mereka untuk login ke layanan di desktop mereka. Kapabilitas ini memungkinkan pengguna melakukan autentikasi dengan aman tanpa perlu mentransfer passkey secara manual atau bergantung pada metode login konvensional untuk setiap perangkat, mendorong pengalaman autentikasi yang terpadu.

Authenticator platform, seperti Windows Hello, Face ID, atau Touch ID, dipasang langsung ke dalam perangkat dan menawarkan pengalaman passkey yang lebih cepat, lebih mulus, dan lebih aman dengan memungkinkan pengguna melakukan autentikasi dengan biometrik atau metode bawaan perangkat lainnya (misalnya pola PIN).

Become part of our Passkeys Community for updates & support.

Join

userVerifyingPlatformAuthenticator memastikan bahwa autentikasi passkey melibatkan verifikasi pengguna, seperti pemindaian sidik jari aktif atau pengenalan wajah, yang memberikan lapisan keamanan ekstra.

Kapabilitas relatedOrigins memungkinkan autentikasi yang mulus di berbagai domain yang dimiliki oleh organisasi yang sama (misalnya amazon.com dan amazon.de). Misalnya, jika sebuah perusahaan mengelola beberapa domain atau memiliki subdomain yang berbeda, pengguna bisa login sekali dan mengakses semua properti tanpa harus melakukan autentikasi ulang di masing-masing domain. Kapabilitas ini menyederhanakan pengalaman pengguna, mengurangi hambatan, dan sangat berharga bagi perusahaan di lingkungan internasional atau dengan platform multilayanan.

Metode signalAllAcceptedCredentials(options) memberikan daftar lengkap Credential ID WebAuthn untuk pengguna tertentu. Relying Party WebAuthn sebaiknya menggunakan metode ini ketimbang signalUnknownCredential() saat pengguna telah terautentikasi, karena tidak ada risiko kebocoran privasi. Metode ini menawarkan gambaran komprehensif tentang kredensial kunci publik pengguna, termasuk perubahan terbaru yang mungkin belum diperbarui pada Authenticator yang saat ini terhubung.

Mari kita lihat sebuah contoh. Seorang pengguna (userId: A) memiliki 2 passkey dengan Credential ID yang dienkode Base64URL ke X dan Y. Kemudian, pengguna menghapus passkey X di pengaturan akun layanan web (example.com) (sehingga kunci publiknya terhapus). Sekarang, jalankan snippet berikut:

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "A", // WebAuthn User Handle, Base64URL.
    allAcceptedCredentialIds: ["Y"],
});

Jika Authenticator tersedia pada saat eksekusi kode di atas, maka Authenticator akan menghapus atau menyembunyikan passkey X dari proses autentikasi di masa mendatang. Namun, Authenticator mungkin tidak terpasang pada saat eksekusi, sehingga sangat disarankan agar Relying Party menjalankan kode ini secara berkala, misalnya pada setiap proses sign-in.

Passkey yang tidak ada dalam allAcceptedCredentialIds akan dihapus atau disembunyikan, dan berpotensi tidak bisa dikembalikan. Jadi, penting bagi Relying Party untuk memastikan bahwa Credential ID WebAuthn yang valid tidak pernah dihapus dari daftar. Jika Credential ID yang valid tidak sengaja terhapus, maka Relying Party harus segera menyertakannya dalam panggilan signalAllAcceptedCredentials(options) yang lain sesegera mungkin untuk "memunculkan kembali" passkey tersebut. Jika passkey tidak disembunyikan melainkan dihapus, maka tidak banyak yang bisa dilakukan untuk memperbaikinya.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Metode signalCurrentUserDetails(options) memberikan sinyal tentang nama pengguna saat ini dan Display Name WebAuthn. Saat signalCurrentUserDetails(options) dipanggil, client akan mengikuti serangkaian langkah yang ditentukan untuk menjalankan tindakan ini.

Mari kita lihat contohnya. Seorang pengguna dengan User ID WebAuthn A memperbarui nama mereka di pengaturan akun sebuah website (example.com). Kemudian, Relying Party bisa menjalankan kode berikut:

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "A", // user ID, Base64URL.
    name: "New user name",
    displayName: "New display name",
});

Authenticator kemudian akan memperbarui metadata passkey yang disimpan secara lokal. Manfaat besarnya adalah pada permintaan Conditional UI / autofill passkey di masa mendatang, pilihan Conditional UI / menu dropdown akan menampilkan nama yang telah diperbarui dan Display Name WebAuthn.

Metode signalUnknownCredential(options) memberikan sinyal bahwa Credential ID WebAuthn tidak dikenali oleh Relying Party WebAuthn, misalnya, jika passkey dihapus oleh pengguna. Berbeda dengan signalAllAcceptedCredentials(options), metode ini tidak memerlukan penyediaan daftar lengkap Credential ID yang diterima dan User Handle WebAuthn, sehingga mencegah potensi kebocoran privasi bagi penelepon yang tidak terautentikasi.

Mari kita lihat sebuah contoh. Seorang pengguna menghapus passkey dengan Credential ID X di pengaturan akun website (example.com) (sehingga kunci publiknya dihapus). Namun, kunci privatnya masih tersedia di perangkat pengguna. Ini berarti bahwa pada permintaan login Conditional UI / autofill passkey di masa mendatang (dengan daftar allowCredentials yang kosong), passkey tersebut masih bisa dipilih. Percobaan login akan gagal, karena kunci publiknya sudah dihapus, sehingga Relying Party sebaiknya menjalankan:

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "X", // credential ID the user just tried, Base64URL
});

Authenticator kemudian akan menghapus atau menyembunyikan passkey dengan Credential ID X dari proses autentikasi di masa mendatang.

Karena standar WebAuthn Level 3 masih berstatus draf, adopsi kapabilitas client baru ini belum sepenuhnya tersebar luas. Berbagai browser secara bertahap telah mengimplementasikan fitur-fitur ini, tetapi dukungannya bervariasi. Di bawah ini adalah gambaran umum terbaru tentang ketersediaan di berbagai browser utama yang disebutkan di atas:

Laju adopsi kemungkinan akan meningkat seiring dengan matangnya Level 3 dan semakin banyak browser yang merilis fitur-fitur ini. Jika Anda ingin melihat berapa banyak pengguna yang dapat memanfaatkan getClientCapabilities() saat ini, Anda bisa memeriksa data dunia nyata menggunakan State of Passkeys secara gratis. Awasi catatan rilis browser dan dokumentasi terkait untuk merencanakan kompatibilitas yang lebih luas seiring perkembangannya.

Want to find out how many people use passkeys?

View Adoption Data

Sebagai developer, Anda mungkin bertanya-tanya apa arti deteksi kapabilitas client WebAuthn yang baru ini bagi Anda dan bagaimana Anda harus menggunakannya di aplikasi Anda. Berikut ini, Anda akan menemukan rekomendasi untuk menggunakannya.

Namun, ketahuilah bahwa belum semua browser mendukung pemanggilan API getClientCapabilities() (hingga November 2024). Ada polyfill yang tersedia di sini, yang bisa digunakan sampai semua browser menyusul.

Gunakan getClientCapabilities() di awal kode Anda untuk mendeteksi fitur yang didukung client pada saat awal pemuatan halaman / alur autentikasi. Ini akan memungkinkan Anda menyesuaikan pengalaman secara dinamis, dan menyediakan fitur passkey yang berfungsi di perangkat / browser, misalnya mendorong autentikasi platform jika didukung atau menawarkan metode alternatif (seperti SMS OTP atau hardware security keys) jika tidak.

Jika Anda menambahkan passkey ke website / aplikasi yang saat ini menggunakan password, fitur conditionalCreate bisa menjadi pendorong nyata bagi adopsi passkey Anda. Di latar belakang, selama proses autofill password dengan credential manager yang sesuai (hanya Apple Passwords per Oktober 2024), passkey secara otomatis dibuat dan akan lebih diutamakan untuk proses autofill di masa mendatang.

Untuk tidak hanya memiliki adopsi passkey yang tinggi, tetapi juga penggunaan login passkey yang tinggi, cobalah untuk memeriksa apakah perangkat / browser bisa menggunakan Conditional UI / Autofill Passkey dengan memeriksa conditionalGet. Dengan cara ini, Anda akan mendorong pengguna untuk menggunakan passkey yang telah dibuat untuk login, karena disarankan secara proaktif oleh sistem operasi / browser dan membutuhkan lebih sedikit upaya daripada mengisi password secara otomatis.

Manfaatkan hybridTransport untuk mengaktifkan autentikasi lintas perangkat (melalui kode QR dan Bluetooth), yang memungkinkan pengguna untuk login dengan mulus dari smartphone mereka, bahkan jika mereka sedang mengakses layanan Anda di desktop.

Kapabilitas client WebAuthn merupakan langkah maju yang signifikan dalam mengatasi celah passkey yang ada saat ini. Di artikel blog ini, kita telah menjawab pertanyaan-pertanyaan utama tentang kapabilitas client WebAuthn:

1. Apa itu kapabilitas client WebAuthn? Kita telah menjelaskan bagaimana fitur ini memungkinkan browser dan platform memberikan sinyal dukungan mereka terhadap fungsionalitas tertentu, memberi developer lebih banyak kontrol atas alur autentikasi.
2. Apa saja kapabilitas client WebAuthn yang ada? Kita memberikan ikhtisar tentang kapabilitas baru yang diperkenalkan dalam standar Level 3, termasuk getClientCapabilities, conditionalCreate, hybridTransport, dan banyak lagi.
3. Bagaimana kapabilitas client WebAuthn meningkatkan implementasi passkey? Kita membahas bagaimana kapabilitas ini menyederhanakan integrasi, meningkatkan penggunaan lintas perangkat, dan menyempurnakan keamanan.
4. Mengapa kapabilitas client WebAuthn penting bagi developer? Fitur-fitur ini membantu menciptakan pengalaman autentikasi yang mulus dan aman yang sejalan dengan ekspektasi pengguna modern, membuat implementasi lebih mudah dan lebih efektif.

Kami mendorong Anda untuk menjelajahi fitur WebAuthn Level 3 yang baru dan terus mengikuti perkembangan adopsinya di berbagai browser. Jika Anda ingin mengimplementasikan passkey dan memanfaatkan kapabilitas canggih ini, hubungi kami untuk mendapatkan panduan dan dukungan ahli.

Panggil getClientCapabilities() lebih awal pada saat memuat halaman atau alur autentikasi untuk mendeteksi fitur yang didukung secara dinamis. Ini memungkinkan Anda menawarkan autentikasi platform saat didukung, atau beralih ke alternatif lain seperti SMS OTP atau kunci keamanan fisik (hardware security keys) jika tidak.

signalAllAcceptedCredentials memerlukan daftar lengkap Credential ID yang valid dan User Handle WebAuthn, jadi metode ini sebaiknya hanya dipanggil saat pengguna telah terautentikasi untuk menghindari kebocoran privasi. signalUnknownCredential memberikan sinyal tentang satu Credential ID yang tidak dikenali tanpa memerlukan daftar lengkap, sehingga aman untuk dipanggil dalam skenario yang tidak terautentikasi seperti setelah upaya login yang gagal.

Kapabilitas relatedOrigins memungkinkan autentikasi yang mulus di berbagai domain yang dimiliki oleh organisasi yang sama, contohnya amazon.com dan amazon.de. Pengguna dapat login sekali dan mengakses semua properti tanpa perlu melakukan autentikasi ulang di setiap domain, yang mengurangi hambatan di lingkungan internasional atau multilayanan.

Hingga November 2024, belum semua browser mendukung getClientCapabilities(), jadi Anda bisa menggunakan polyfill yang tersedia di github.com/MasterKale/webauthn-polyfills sebagai solusi sementara. Adopsi ini diperkirakan akan meningkat seiring dengan semakin matangnya standar WebAuthn Level 3 dan karena Chrome 133, Edge 133, Firefox 135, dan Safari 17.4 kini telah merilis dukungannya.