WebAuthn Signal API: Memperbarui & Menghapus Passkey di Sisi Klien

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

Get Cheat Sheet

Terakhir diperbarui: 4 November 2025

Berikut adalah ringkasan cepat mengenai dukungan WebAuthn Signal API di berbagai platform:

⚠️ Masalah yang Diketahui: Safari 26+ memiliki bug di mana promise tidak terselesaikan dengan benar (WebKit Bug #298951). Perbaikan sedang menunggu proses merge.

Ekosistem passkey terus berkembang. Untuk memfasilitasi perubahan ini, standar WebAuthn yang mendasarinya juga berevolusi dengan cepat. Fitur-fitur baru sering kali dimulai dari penjelasan teknis (technical explainer) di GitHub, lalu berkembang menjadi pull request ke dalam standar setelah didiskusikan secara matang. Baru-baru ini, pull request ini telah ditambahkan ke dalam draf standar sebagai WebAuthn Signal API.

Di artikel ini, kita akan membahas:

• Mengapa WebAuthn Signal API dibutuhkan: Kasus penggunaan apa saja yang didukung oleh WebAuthn Signal API?
• Cara kerja WebAuthn Signal API: Bagaimana tepatnya API ini bekerja? Apa rekomendasinya bagi Relying Party?

Saat artikel ini ditulis, WebAuthn Signal API sudah diaktifkan secara default sejak Chrome 132. Sebelumnya, fitur ini dikenal sebagai Reporting API sebelum namanya diganti untuk menghindari konflik dengan API lain yang bernama sama.

WebAuthn Signal API menjawab kebutuhan spesifik terkait pengelolaan passkey di sisi klien (client-side). Secara khusus, API ini membantu menjaga sinkronisasi informasi antara Relying Party (RP) dan authenticator yang menjadi bagian dari sistem operasi di sisi klien. Berikut adalah beberapa kasus penggunaan penting:

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Saat passkey dibuat, ada beberapa informasi yang disertakan: user.id, user.name, dan user.displayName. Passkey itu sendiri diidentifikasi melalui Credential ID yang unik.

• user.id: adalah pengenal unik yang mewakili akun tempat passkey ditautkan. user.id ini sangat krusial karena digunakan untuk mencocokkan passkey dengan akun pengguna yang sebenarnya.
• user.name dan user.displayName: ini adalah metadata yang digunakan semata-mata untuk tujuan tampilan di antarmuka pengguna (UI).

Ilustrasi berikut menunjukkan struktur database sederhana yang menjelaskan informasi mana yang biasanya disimpan di kolom (field) mana:

Penting untuk dipahami bahwa meskipun user.name (sering kali berupa alamat email) dan user.displayName (nama yang lebih mudah dibaca) membantu pengguna mengidentifikasi akun mereka di UI pemilihan, asosiasi nyata antara passkey dan akun tetap dijaga melalui user.id dan Credential ID:

• Sebuah akun bisa memiliki banyak passkey, tetapi setiap passkey secara unik diidentifikasi dan dicocokkan ke akun menggunakan user.id.
• Setiap passkey itu sendiri memiliki Credential ID unik yang dibuat oleh authenticator.

Masalah muncul ketika user.name (misalnya alamat email) berubah. Saat ini, tidak ada mekanisme untuk memperbarui perubahan ini secara langsung di authenticator sisi klien. user.name bisa berubah karena berbagai alasan, seperti saat pengguna mengganti alamat email mereka. Meskipun metadata akun di sisi server sudah berubah, user.name yang lama akan terus muncul di UI pemilihan kredensial, yang bisa membingungkan pengguna.

Solusi sementara (workaround) untuk masalah ini adalah membuat passkey baru dengan user.name yang sudah diperbarui dan user.id yang sama, lalu menimpa passkey yang ada. Namun, pendekatan ini merepotkan karena beberapa alasan:

1. Redundansi: Authenticator hanya dapat menyimpan satu passkey per user.id untuk ID Relying Party tertentu. Artinya, passkey lama harus diganti dengan yang baru hanya untuk memperbarui metadata, yang merupakan langkah tambahan.
2. User Experience (UX): Pengguna tidak akan mengerti mengapa mereka perlu membuat passkey baru. Itulah sebabnya solusi ini tidak banyak digunakan.
3. Kompleksitas: Mengelola pembuatan passkey dan penggantian hanya untuk memperbarui metadata adalah kerumitan yang tidak perlu.

Alamat email, nomor telepon, dan pengenal lainnya bisa berubah secara berkala. Tanpa metode yang mudah untuk memperbarui user.name dan user.displayName langsung di authenticator, pengguna mungkin akan terus melihat dan harus memilih passkey yang terkait dengan email lama mereka. Situasi ini merusak pengalaman mulus yang ingin ditawarkan oleh passkey. WebAuthn Signal API bertujuan untuk memecahkan masalah ini dengan memungkinkan Relying Party melaporkan pembaruan metadata passkey tanpa perlu membuat passkey baru. Sebelum kita membahas cara mengimplementasikan Signal API, mari kita lihat kasus penggunaan penting kedua.

Become part of our Passkeys Community for updates & support.

Join

Kasus penggunaan penting lainnya adalah penghapusan passkey di authenticator sisi klien. Seiring waktu, pengguna mungkin mencabut kredensial melalui daftar manajemen passkey atau menghapus akun mereka, dan kita perlu memastikan bahwa kredensial ini dihapus dari authenticator sisi klien agar tidak muncul lagi di UI pemilihan kredensial di masa mendatang (Conditional UI / passkey autofill).

Kebutuhan akan fungsionalitas ini muncul dalam beberapa skenario:

1. Passkey dihapus melalui pengaturan akun: Ketika kredensial tidak lagi valid, misalnya setelah pengguna secara eksplisit menghapusnya melalui pengaturan akun:

Dari sudut pandang pengguna, sulit untuk memahami bahwa penghapusan di pengaturan akun mereka (seperti dialog di atas) tidak secara otomatis menghapus passkey di perangkat klien ini.

2. Penghapusan Akun: Ketika pengguna menghapus akun mereka, semua passkey yang terkait juga harus dihapus.

3. Kebijakan Keamanan: Relying Party mungkin memiliki kebijakan keamanan yang mengharuskan pencabutan kredensial setelah periode tidak aktif tertentu atau karena masalah keamanan yang terdeteksi.

Tanpa metode langsung untuk menghapus passkey di sisi klien, kredensial yang sudah kedaluwarsa atau tidak valid ini akan terus memenuhi UI pemilihan, yang menyebabkan kebingungan. Pengguna mungkin melihat dan mencoba menggunakan passkey yang sudah tidak valid, mengakibatkan kegagalan autentikasi dan pengalaman pengguna yang buruk.

Lihat video ini tentang cara menghapus passkey sisi server di Corbado Connect Management Console:

Mengimplementasikan WebAuthn Signal API melibatkan beberapa langkah dan pertimbangan untuk memastikan fungsionalitasnya terintegrasi dengan benar dan aman. Signal API memungkinkan Relying Party (RP) untuk memperbarui atau menghapus kredensial passkey di authenticator sisi klien. Bagian ini menguraikan pertimbangan utama dan langkah-langkah implementasinya.

Saat mengimplementasikan WebAuthn Signal API, sangat penting untuk mengingat hal-hal berikut:

• Menjaga Privasi: WebAuthn Signal API dirancang untuk menjaga privasi pengguna karena ini adalah salah satu fondasi WebAuthn. Artinya, tidak ada umpan balik yang diberikan kepada RP tentang apakah perubahan yang diminta berhasil diproses. API ini beroperasi secara diam-diam (silent) untuk mencegah potensi kebocoran informasi tentang status kredensial.

• Ketersediaan Authenticator: Efektivitas WebAuthn Signal API bergantung pada ketersediaan authenticator. Ini mencakup ketersediaan fisik dan dukungan perangkat lunak (misalnya, kompatibilitas browser dan sistem operasi). Browser hanya dapat melakukan tindakan jika authenticator dapat diakses dan mendukung operasi yang diperlukan tanpa memerlukan autentikasi biometrik.

• Batasan Domain: API memastikan bahwa hanya Relying Party yang terkait dengan domain tertentu yang dapat meminta perubahan pada kredensial yang terkait dengan domain tersebut. Ini adalah langkah keamanan untuk mencegah modifikasi tidak sah oleh pihak ketiga.

• Credential ID sebagai Kunci: Saat merujuk passkey, Credential ID adalah kunci utama yang digunakan oleh WebAuthn Signal API. ID ini secara unik mengidentifikasi passkey di authenticator sisi klien. API memungkinkan RP untuk mengubah metadata yang terkait dengan passkey atau memberi sinyal bahwa passkey tertentu tidak boleh lagi diakses, tetapi hanya melalui Credential ID. Jika authenticator tidak mengenali Credential ID tertentu, ia akan mengabaikannya secara diam-diam.

Pertimbangan ini sangat penting untuk memahami aspek paling krusial agar WebAuthn Signal API berfungsi dengan benar.

WebAuthn Signal API menyediakan mekanisme yang efisien bagi Relying Party (RP) untuk memperbarui metadata yang terkait dengan passkey di authenticator sisi klien. Ini sangat penting untuk memastikan pengguna melihat informasi yang akurat dan terkini di UI pemilihan kredensial tanpa harus membuat passkey baru yang tidak perlu. Begini cara API ini mewujudkannya:

Memperbarui Metadata dengan signalCurrentUserDetails(options)

Metode signalCurrentUserDetails(options) dalam Signal API dirancang khusus untuk memperbarui metadata passkey. Metode ini memungkinkan RP memberikan nilai terbaru untuk user.name dan user.displayName.

Berikut proses kerjanya (lihat juga standar WebAuthn Level 3).

1. Struktur Metode: Metode signalCurrentUserDetails(options) mencakup rp.id, user.id, serta nilai terbaru untuk user.name dan user.displayName.

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    name: "New user name",
    displayName: "New display name",
});

2. Memperbarui Metadata Lokal: Authenticator akan mencari kredensial yang tersedia secara lokal yang cocok dengan rpId dan userId. Untuk semua kredensial yang cocok, authenticator akan memperbarui name dan displayName kredensial tersebut.

3. Menjaga Privasi: Proses ini dirancang untuk menjaga privasi. Signal API tidak memberikan umpan balik kepada RP tentang apakah pembaruan berhasil diproses, mencegah kebocoran informasi tentang status kredensial.

4. Konsistensi di Seluruh Perangkat: Dengan menjalankan metode signalCurrentUserDetails(options) secara teratur, RP dapat memastikan bahwa metadata untuk passkey tetap konsisten di berbagai perangkat dan platform tempat pengguna melakukan autentikasi. Pendekatan ini mengurangi kemungkinan informasi usang atau salah ditampilkan di UI pemilihan kredensial.

Pada tangkapan layar di atas, Anda dapat melihat bagaimana Google Chrome memberi sinyal pembaruan tersebut kepada pengguna. WebAuthn Signal API adalah bagian dari Chrome dan dapat diuji dengan Google Password Manager di desktop.

WebAuthn Signal API menyediakan mekanisme bagi Relying Party (RP) untuk memberi sinyal penghapusan passkey dari authenticator sisi klien. Ini penting untuk memastikan bahwa kredensial yang usang atau tidak valid tidak muncul di UI pemilihan kredensial, sehingga menjaga pengalaman pengguna yang rapi dan aman. Ada dua metode untuk menghapus passkey secara lokal: signalUnknownCredential(options) dan signalAllAcceptedCredentials(options). Metode pertama dapat digunakan dalam situasi di mana pengguna tidak terautentikasi, sedangkan metode kedua dapat digunakan saat pengguna terautentikasi. Oleh karena itu, metode kedua lebih disukai karena alasan privasi.

Berikut cara kerja kedua metode tersebut:

1. Struktur Metode: Metode signalUnknownCredential(options) mencakup rpId (ID Relying Party) dan credentialId (pengenal unik dari kredensial yang akan dihapus).

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // credential id yang baru saja dicoba user, base64url
});

2. Memanggil Metode: RP memanggil metode ini kapan pun mereka mendeteksi bahwa sebuah kredensial harus dihapus. Ini bisa segera setelah upaya autentikasi dengan kredensial yang tidak valid, selama penghapusan akun, atau ketika pengguna mencabut kredensial melalui pengaturan akun.

3. Penanganan Metode: Saat metode signalUnknownCredential(options) dipanggil, authenticator sisi klien mencoba menemukan kredensial yang cocok dengan rpId dan credentialID yang ditentukan untuk dihilangkan. Tergantung pada kemampuan authenticator, kredensial akan dihapus atau prosedur khusus authenticator akan menyembunyikan kredensial tersebut dalam proses autentikasi di masa mendatang.

1. Struktur Metode: Metode signalAllAcceptedCredentials(options) mencakup rpId (ID Relying Party), userId, dan daftar Credential ID yang valid allAcceptedCredentialIds (daftar pengenal unik kredensial yang harus disimpan).

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    allAcceptedCredentialIds: ["bb"],
});

2. Memanggil Metode: RP memanggil metode ini kapan pun mereka mendeteksi bahwa kredensial harus dihapus dan memberikan sinyal daftar kredensial yang masih valid. Metode ini sebaiknya lebih diutamakan dibandingkan signalUnknownCredential(options) untuk menghapus kredensial.

3. Penanganan Metode: Saat metode signalAllAcceptedCredentials(options) dipanggil, authenticator sisi klien mencocokkan rpId dan userId. Authenticator kemudian mencari semua kredensial lokal yang cocok dengan rpId dan userId. Hasilnya dibandingkan dengan allAcceptedCredentialIds. Jika ada kredensial lokal yang tidak ada dalam allAcceptedCredentialIds, maka kredensial tersebut dihapus secara lokal (atau disembunyikan tergantung pada authenticator).

4. Memunculkan Kembali Kredensial: Jika kredensial hanya disembunyikan (tergantung pada authenticator) dan sekarang menjadi bagian dari allAcceptedCredentialIds lagi, maka kredensial ini akan hadir kembali dalam proses autentikasi di masa depan.

5. Tips Bermanfaat:

   • Saat menggunakan signalAllAcceptedCredentials(options), penting untuk dicatat bahwa authenticator mungkin tidak selalu terhubung pada saat metode ini dijalankan. Akibatnya, Relying Party bisa mempertimbangkan untuk menjalankan signalAllAcceptedCredentials(options) secara berkala, seperti pada setiap proses masuk (sign-in), untuk memastikan semua kredensial mutakhir.
   • Relying Party harus berhati-hati saat menentukan daftar ID kredensial (allAcceptedCredentialIds). Kredensial yang tidak termasuk dalam daftar ini mungkin disembunyikan atau dihapus oleh authenticator, yang berpotensi tidak dapat dikembalikan. Untuk mencegah kredensial valid terhapus secara tidak sengaja, sangat penting untuk memastikan daftarnya lengkap. Jika ID kredensial yang valid secara tidak sengaja tertinggal, ID tersebut harus ditambahkan kembali ke signalAllAcceptedCredentials(options) sesegera mungkin agar terlihat lagi, dengan asumsi authenticator mendukung hal ini.
   • Jika memungkinkan, authenticator sebaiknya lebih memilih untuk menyembunyikan kredensial sementara daripada menghapusnya secara permanen. Pendekatan ini dapat membantu memfasilitasi pemulihan jika ID kredensial yang valid secara tidak sengaja dihilangkan oleh Relying Party, memungkinkannya dipulihkan tanpa kehilangan permanen.

Pada tangkapan layar di atas, Anda dapat melihat bagaimana Google Chrome memberi sinyal penghapusan. WebAuthn Signal API dapat diuji dengan Google Password Manager di desktop.

Untuk mengimplementasikan WebAuthn Signal API secara efektif dan memastikan sinkronisasi metadata passkey yang mulus di seluruh authenticator sisi klien, pertimbangkan rekomendasi berikut:

• Pantau pembaruan WebAuthn Signal API dan implementasi aktualnya: Tetap terinformasi tentang perkembangan dan pembaruan terbaru terkait Signal API. WebAuthn Signal API diaktifkan dengan Google Chrome 132, diikuti oleh browser lain (misalnya Safari juga mengumumkan dukungannya). Periksa kemajuan dan pembaruan WebAuthn Signal API secara berkala untuk memastikan implementasi Anda selaras dengan standar dan praktik terbaru. Kami akan memperbarui artikel blog ini seiring berkembangnya situasi.
• Mulai dengan pendekatan signalAllAcceptedCredentials(options) setelah setiap login berhasil: Pendekatan ini memastikan bahwa semua metadata dan ID kredensial diperbarui dalam satu metode, menyederhanakan proses dan menjaga konsistensi di seluruh perangkat dan platform, sekaligus menonaktifkan kredensial yang dihapus atau usang.
• Pesan waktu nyata (real-time) dengan signalUnknownCredential(options) untuk penerapan skala besar: Pertimbangkan menggunakan pesan real-time dengan metode signalUnknownCredential(options) dalam penerapan skala besar atau ketika ada kebutuhan untuk pembaruan segera. Metode ini dapat meningkatkan efisiensi dan akurasi manajemen kredensial, memastikan bahwa kredensial yang tidak valid atau usang segera dihapus dari UI pemilihan.

Dengan mengikuti rekomendasi ini, Anda dapat mengimplementasikan WebAuthn Signal API secara efektif setelah didukung, memastikan metadata passkey tetap mutakhir dan konsisten di semua authenticator sisi klien, sehingga memberikan pengalaman pengguna yang lancar dan aman untuk passkey.

Standar WebAuthn terus berkembang, menjadi semakin kaya fitur setiap bulannya. Pengenalan WebAuthn Signal API adalah langkah maju yang signifikan dalam mengelola metadata passkey dan penghapusan di authenticator sisi klien. API ini menjawab kasus penggunaan krusial untuk menjaga sinkronisasi informasi antara Relying Party (RP) dan authenticator, serta memastikan passkey yang tidak valid atau usang dihapus, sehingga meningkatkan pengalaman pengguna.

• Mengapa Signal API dibutuhkan? Signal API sangat penting untuk memperbarui metadata passkey dan menghapus passkey di authenticator sisi klien. Ini menyelesaikan masalah terkait informasi user.name dan user.displayName yang usang, yang dapat menyebabkan kebingungan saat kredensial ditampilkan di UI pemilihan. Selain itu, ini membantu menjaga antarmuka pemilihan kredensial tetap bersih dan aman dengan menghapus passkey yang dicabut atau dihapus.
• Bagaimana cara kerja Signal API? Signal API bekerja dengan memungkinkan RP memanggil metode tentang status kredensial saat ini, termasuk pembaruan metadata dan memberi sinyal penghapusan passkey. Laporan ini diproses oleh authenticator sisi klien, memastikan informasi yang disajikan kepada pengguna akurat dan mutakhir. API ini dirancang untuk menjaga privasi dan beroperasi tanpa memberikan umpan balik kepada RP tentang keberhasilan pembaruan.

Seiring berkembangnya standar WebAuthn, standar ini mendapat manfaat dari beragam kepentingan para pesertanya, yang mendorong berbagai bagian standar ke depan. Mengawasi perkembangan ini sangat penting untuk tetap mengetahui peningkatan terbaru dan memastikan implementasi tetap selaras dengan praktik terbaik dan standar terkini. Komunitas WebAuthn terus mendorong inovasi, membuat autentikasi menjadi lebih aman dan ramah pengguna.