WebAuthn Signal API: Memperbarui & Menghapus Passkey di Sisi Klien

Ekosistem passkey terus berkembang. Untuk memfasilitasi perubahan, standar WebAuthn yang mendasarinya juga berkembang pesat. Fitur-fitur baru sering kali dimulai dengan penjelasan teknis di GitHub, kemudian berkembang menjadi pull request ke dalam standar setelah didiskusikan secara memadai. Baru-baru ini, pull request ini ditambahkan ke dalam draf standar sebagai WebAuthn Signal API. Dalam artikel ini, kita akan membahas:

• Mengapa WebAuthn Signal API dibutuhkan: Kasus penggunaan apa saja yang didukung oleh WebAuthn Signal API?
• Bagaimana cara kerja WebAuthn Signal API: Bagaimana tepatnya WebAuthn Signal API bekerja? Apa saja rekomendasi untuk relying party?

Saat artikel blog ini diperbarui pada Januari 2025, WebAuthn Signal API diaktifkan secara default sejak Chrome 132 dan sebelumnya dikenal sebagai Reporting API sebelum diubah namanya untuk menghindari konflik dengan API lain yang memiliki nama sama.

WebAuthn Signal API menjawab kasus penggunaan spesifik yang berkaitan dengan manajemen passkey di sisi klien. Secara khusus, API ini membantu menjaga sinkronisasi informasi antara relying party (RP) dan autentikator yang merupakan bagian dari sistem operasi sisi klien. Berikut adalah beberapa kasus penggunaan penting yang ada:

Subscribe to our Passkeys Substack for the latest news.

Subscribe

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

• user.id: adalah pengidentifikasi unik yang mewakili akun tempat passkey ditautkan. user.id ini sangat penting karena digunakan untuk pencocokan aktual passkey dengan akun pengguna.
• user.name dan user.displayName: ini adalah meta-data yang digunakan semata-mata untuk tujuan tampilan di antarmuka pengguna.

Ilustrasi berikut menunjukkan struktur database sederhana yang menjelaskan informasi apa yang biasanya disimpan di setiap bidang:

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

• Sebuah akun dapat memiliki beberapa passkey, tetapi setiap passkey diidentifikasi secara unik dan dicocokkan dengan akun menggunakan user.id
• Setiap passkey itu sendiri memiliki Credential ID unik yang dibuat oleh autentikator

Satu masalah muncul ketika user.name, yang bisa berupa alamat email, berubah. Saat ini, tidak ada mekanisme untuk memperbarui perubahan ini di autentikator sisi klien secara langsung. user.name dapat berubah karena berbagai alasan, seperti saat pengguna memperbarui alamat email mereka. Meskipun ada perubahan pada meta-data akun di sisi server, user.name yang lama akan terus muncul di UI pemilihan kredensial, yang dapat menyebabkan kebingungan bagi pengguna.

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

1. Redundansi: Setiap user.id hanya dapat memiliki satu passkey per ID relying party, yang berarti passkey lama harus diganti dengan yang baru, yang merupakan langkah tambahan.
2. Pengalaman Pengguna: Pengguna tidak akan mengerti mengapa mereka perlu membuat passkey baru. Itulah alasan mengapa solusi sementara ini tidak banyak digunakan.
3. Kompleksitas: Mengelola pembuatan passkey dan penggantian hanya untuk memperbarui metadata adalah kompleksitas yang tidak perlu.

Alamat email, nomor telepon, dan pengidentifikasi lainnya dapat berubah secara berkala. Tanpa metode yang mudah untuk memperbarui user.name dan user.displayName secara langsung di autentikator, pengguna mungkin akan terus menghadapi masalah di mana mereka melihat dan harus memilih passkey yang terkait dengan alamat email lama mereka. Situasi ini merusak pengalaman mulus yang ingin dihadirkan oleh passkey. WebAuthn Signal API bertujuan untuk menyelesaikan masalah ini dengan memungkinkan relying party melaporkan pembaruan pada meta-data passkey tanpa perlu membuat yang baru. Sebelum kita menjelaskan cara mengimplementasikan Signal API, kita akan menjelajahi kasus penggunaan penting kedua yang ditanganinya.

Become part of our Passkeys Community for updates & support.

Join

Kasus penggunaan penting lainnya adalah penghapusan passkey di autentikator sisi klien. Seiring waktu, pengguna mungkin mencabut kredensial melalui daftar manajemen passkey atau menghapus akun mereka, dan menjadi perlu untuk memastikan bahwa kredensial ini dihapus dari autentikator sisi klien untuk mencegahnya muncul 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 sebuah kredensial tidak lagi valid, seperti setelah pengguna secara eksplisit menghapusnya melalui pengaturan akun:

Dari sudut pandang pengguna, sulit untuk memahami bahwa penghapusan di pengaturan akun mereka, dalam dialog seperti di atas, tidak menyebabkan passkey dihapus di klien ini.

2. Penghapusan Akun: Ketika seorang 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 atau karena masalah keamanan yang terdeteksi.

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

Mengimplementasikan WebAuthn Signal API melibatkan beberapa langkah dan pertimbangan untuk memastikan bahwa fungsionalitas terintegrasi dengan benar dan aman. Signal API memungkinkan relying party (RP) untuk memperbarui atau menghapus kredensial passkey di autentikator sisi klien. Bagian ini menguraikan pertimbangan dan langkah-langkah utama untuk implementasi.

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

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

• Ketersediaan Autentikator: Efektivitas WebAuthn Signal API bergantung pada ketersediaan autentikator. Ini mencakup ketersediaan fisik (misalnya, adanya kunci keamanan) dan dukungan perangkat lunak (misalnya, kompatibilitas browser dan sistem operasi). Browser hanya dapat melakukan tindakan jika autentikator 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 yang tidak sah oleh pihak ketiga.

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

Pertimbangan ini penting untuk memahami aspek terpenting agar fungsi WebAuthn Signal API berjalan dengan benar.

WebAuthn Signal API menyediakan mekanisme yang disederhanakan bagi relying party (RP) untuk memperbarui metadata yang terkait dengan passkey di autentikator sisi klien. Ini sangat penting untuk memastikan bahwa pengguna melihat informasi yang akurat dan terkini di UI pemilihan kredensial tanpa harus membuat passkey baru yang tidak perlu. Berikut cara API memungkinkan hal ini terjadi:

Memperbarui Metadata dengan signalCurrentUserDetails(options)

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

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

1. Struktur Metode: Metode signalCurrentUserDetails(options) mencakup rp.id, user.id, dan nilai yang diperbarui 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: Cari kredensial yang tersedia secara lokal (di autentikator) yang cocok dengan rpId dan userId. Untuk semua kredensial yang cocok, autentikator 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, sehingga 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 mungkin melakukan autentikasi. Pendekatan ini mengurangi kemungkinan informasi yang usang atau salah ditampilkan di UI pemilihan kredensial.

Pada tangkapan layar di atas, Anda dapat melihat bagaimana Google Chrome memberi sinyal pembaruan semacam itu kepada pengguna. WebAuthn Signal API adalah bagian dari Chrome 130 dan dapat diuji dengan Google Password Manager di desktop jika flag fitur web eksperimental diaktifkan.

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

Berikut cara kerja kedua metode tersebut:

1. Struktur Metode: Metode signalUnknownCredential(options) mencakup rpId (ID relying party) dan credentialId (pengidentifikasi unik dari kredensial yang akan dihapus).

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // credential id the user just tried, base64url
});

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

3. Menangani Metode: Ketika metode signalUnknownCredential(options) dipanggil, autentikator sisi klien mencoba menemukan kredensial yang cocok dengan rpId dan credentialID yang ditentukan untuk dihilangkan. Tergantung pada kemampuan autentikator, kredensial tersebut dihapus atau prosedur spesifik autentikator untuk menyembunyikan kredensial dalam seremoni autentikasi di masa mendatang akan digunakan.

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

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

2. Memanggil Metode: RP memanggil metode ini setiap kali mereka mendeteksi bahwa sebuah kredensial harus dihapus dan memberi sinyal daftar kredensial yang valid. Metode ini lebih disukai daripada signalUnknownCredential(options) untuk menghapus kredensial.

3. Menangani Metode: Ketika metode signalAllAcceptedCredentials(options) dipanggil, autentikator sisi klien mencocokkan rpId dan userId. Autentikator akan mencari semua kredensial lokal yang cocok dengan rpId dan userId. Hasilnya dibandingkan dengan allAcceptedCredentialIds. Jika ada kredensial lokal yang tidak ada di allAcceptedCredentialIds, maka kredensial tersebut akan dihapus secara lokal (atau disembunyikan tergantung pada autentikator).

4. Menampilkan Kembali Kredensial: Jika kredensial hanya disembunyikan (tergantung pada autentikator) dan sekarang menjadi bagian dari allAcceptedCredentialIds, maka kredensial ini akan muncul kembali dalam seremoni autentikasi di masa mendatang.

5. Tips Berguna:

   • Saat menggunakan signalAllAcceptedCredentials(options), penting untuk dicatat bahwa autentikator mungkin tidak selalu terhubung saat metode ini dijalankan. Akibatnya, relying party mungkin perlu mempertimbangkan untuk menjalankan signalAllAcceptedCredentials(options) secara berkala, seperti saat setiap kali masuk, untuk memastikan bahwa semua kredensial sudah diperbarui.
   • Relying party harus berhati-hati saat menentukan daftar ID kredensial (allAcceptedCredentialIds). Kredensial yang tidak termasuk dalam daftar ini dapat disembunyikan atau dihapus oleh autentikator, yang berpotensi tidak dapat diubah. Untuk mencegah kredensial yang valid terlewat secara tidak sengaja, sangat penting untuk memastikan bahwa daftarnya lengkap. Jika ID kredensial yang valid secara tidak sengaja tertinggal, ID tersebut harus ditambahkan kembali ke signalAllAcceptedCredentials(options) sesegera mungkin untuk membuatnya terlihat lagi, dengan asumsi autentikator mendukung hal ini.
   • Jika memungkinkan, autentikator 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, sehingga memungkinkan untuk dipulihkan tanpa kehilangan permanen.

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

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

• Perhatikan pembaruan WebAuthn Signal API dan implementasi aktual: 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 pada WebAuthn Signal API secara teratur untuk memastikan implementasi Anda sejalan dengan standar dan praktik terbaru. Kami akan memperbarui posting blog ini di masa mendatang, saat ini didasarkan pada informasi yang tersedia per 14 Januari 2025.
• Mulai dengan pendekatan signalAllAcceptedCredentials(options) setelah setiap login yang 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 real-time dengan signalUnknownCredential(options) untuk penerapan skala besar: Pertimbangkan untuk 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 bahwa metadata passkey tetap terkini dan konsisten di semua autentikator sisi klien, sehingga memberikan pengalaman pengguna yang lancar dan aman untuk passkey.

Standar WebAuthn terus berkembang, menjadi lebih kaya fitur setiap bulannya. Pengenalan WebAuthn Signal API adalah langkah maju yang signifikan dalam mengelola meta-data passkey dan penghapusan di autentikator sisi klien. API ini menjawab kasus penggunaan penting untuk menjaga sinkronisasi informasi antara relying party (RP) dan autentikator, serta memastikan bahwa 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 autentikator sisi klien. Ini menyelesaikan masalah terkait informasi user.name dan user.displayName yang usang, yang dapat menyebabkan kebingungan saat kredensial disajikan di UI pemilihan. Selain itu, ini membantu dalam menjaga antarmuka pemilihan kredensial yang 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 autentikator sisi klien, memastikan bahwa informasi yang disajikan kepada pengguna akurat dan terkini. 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 up-to-date dengan peningkatan terbaru dan memastikan bahwa implementasi tetap sejalan dengan praktik dan standar terbaik terbaru. Komunitas WebAuthn terus mendorong inovasi, membuat autentikasi lebih aman dan ramah pengguna.