Transport WebAuthn: Transport Internal dan Hybrid

Whitepaper Passkey Enterprise. Panduan praktis, pola peluncuran, dan KPI untuk program passkeys.

Dapatkan whitepaper

Catatan: Sesuai spesifikasi WebAuthn, urutan transport yang kosong berarti informasi transport tidak tersedia atau disembunyikan untuk privasi. Sering kali diperlakukan oleh browser seolah-olah semua transport mungkin tersedia.

Saat menerapkan kunci sandi (passkeys) di berbagai platform, pengembang menghadapi keputusan penting:

• Bagaimana Anda harus menangani transport WebAuthn, terutama transport internal dan hybrid, untuk memastikan pengalaman autentikasi lintas perangkat yang optimal?

Jawabannya terletak pada pemahaman tentang transport WebAuthn—detail teknis yang menentukan bagaimana autentikator berkomunikasi dengan pihak yang mengandalkan (relying parties). Meskipun transport tampak sederhana dalam teori, penerapannya bervariasi secara signifikan di seluruh browser web, aplikasi iOS asli (native), dan aplikasi Android asli, khususnya untuk penanganan transport internal dan hybrid.

Artikel ini membahas cara kerja transport WebAuthn di berbagai platform dan menyajikan dua pendekatan berbeda untuk menangani transport internal dan hybrid—masing-masing dengan pertukarannya sendiri (trade-offs).

Artikel ini membahas:

1. Transport WebAuthn: internal, hybrid, dan autentikator platform di seluruh web, iOS, dan Android
2. Dua pendekatan: penanganan transport internal dan hybrid yang sesuai spesifikasi vs. yang dioptimalkan
3. Praktik terbaik dan rekomendasi implementasi autentikasi lintas perangkat

Transport WebAuthn mendefinisikan metode komunikasi antara autentikator dan perangkat klien. Spesifikasi WebAuthn Level 3 mendefinisikan enam jenis transport:

usb: Digunakan oleh kunci keamanan perangkat keras yang terhubung melalui port USB, seperti YubiKey atau token keamanan FIDO2 lainnya.

nfc: Memungkinkan komunikasi dengan autentikator melalui Near Field Communication, memungkinkan pengguna untuk mengetuk kunci keamanan atau perangkat yang mendukung NFC mereka.

ble: Memfasilitasi autentikasi melalui Bluetooth Low Energy, memungkinkan komunikasi nirkabel dengan autentikator eksternal.

smart-card: Digunakan untuk pembaca kartu pintar, memungkinkan autentikasi melalui kartu pintar (smart cards).

hybrid: Memungkinkan autentikasi lintas perangkat, biasanya di mana pengguna memindai kode QR untuk mengautentikasi di seluruh perangkat—seperti menggunakan ponsel untuk mengautentikasi di browser desktop, atau sebaliknya. Transport ini dapat memicu perintah kode QR di perangkat desktop dan seluler, yang mungkin tidak selalu diinginkan tergantung pada konteksnya. Catatan: hybrid ditambahkan di WebAuthn Level 3.

internal: Autentikator tertanam di dalam perangkat itu sendiri—seperti iCloud Keychain (diverifikasi melalui Face ID atau Touch ID) di iPhone, Windows Hello di PC, atau Google Password Manager di perangkat Android. Ini adalah autentikator platform.

Saat kunci sandi dibuat, autentikator memberi sinyal transport mana yang didukungnya. Informasi ini dikirim ke pihak yang mengandalkan (backend Anda), yang harus menyimpannya bersama dengan kredensial tersebut. Selama autentikasi, pihak yang mengandalkan mengirimkan transport ini kembali ke klien dalam daftar allowCredentials, membantu browser atau platform menentukan metode autentikasi mana yang akan ditawarkan kepada pengguna.

Penanganan transport berbeda secara signifikan antar platform, menciptakan tantangan kompatibilitas yang dihadapi pengembang.

Browser menerima informasi transport dari autentikator dan menghormatinya selama alur autentikasi. Saat Anda membuat kunci sandi di Chrome, Safari, atau Edge, pengelola kredensial browser memberikan data transport yang bervariasi berdasarkan autentikator yang mendasarinya:

Autentikator platform: Windows Hello menyediakan ["internal"] saja, yang mencerminkan sifatnya yang terikat ke perangkat (device-bound). Namun, saat Chrome menggunakan Google Password Manager sebagai autentikator, ia memberikan ["internal", "hybrid"] karena Google Password Manager mendukung autentikasi lintas perangkat melalui Ponsel Android.

Kunci keamanan perangkat keras: Menyediakan transport khusus seperti ["usb", "nfc"] berdasarkan kemampuan aktualnya.

Pengelola kredensial tersinkronisasi awan (Cloud-synced): iCloud Keychain di Safari dan Google Password Manager di Chrome biasanya menyediakan ["internal", "hybrid"] untuk mendukung alur autentikasi lokal dan lintas perangkat.

Informasi ini mengalir dengan andal dalam konteks web, meskipun transport tertentu bergantung pada autentikator mana yang dipilih browser untuk penyimpanan kredensial.

Dokumentasi: Spesifikasi W3C WebAuthn

Credential Manager API Android berperilaku mirip dengan browser web. Saat membuat kunci sandi di aplikasi Android asli, Credential Manager menyediakan informasi transport yang mencerminkan perilaku web—autentikator platform melaporkan kemampuannya secara akurat, dan sistem menangani data transport secara konsisten. Pengembang Android dapat mengandalkan informasi ini tanpa penanganan khusus.

Dokumentasi: Android Credential Manager

iOS menghadirkan situasi yang lebih kompleks. Kerangka kerja AuthenticationServices Apple menangani transport secara berbeda bergantung pada jenis autentikator:

Autentikator platform (iCloud Keychain, diverifikasi melalui Face ID atau Touch ID): Sering kali mengembalikan array transport kosong selama pembuatan kunci sandi. Hal ini menunjukkan bahwa informasi transport tidak tersedia atau dirahasiakan untuk privasi—menurut spesifikasi WebAuthn, agen pengguna dapat mengembalikan urutan kosong jika informasi transport tidak diketahui atau untuk menjaga privasi. Pihak yang mengandalkan (relying parties) harus memperlakukan transport sebagai petunjuk dan bukan sebagai jaminan.

Kunci keamanan: Benar-benar memberikan informasi transport (mis., ["usb"], ["nfc"]) saat digunakan dengan perangkat iOS, mengikuti pola yang diharapkan.

Dokumentasi: Apple AuthenticationServices

Data produksi dunia nyata dari aplikasi web dan asli mengungkapkan pola transport berikut, diurutkan berdasarkan frekuensi. Perhatikan bahwa distribusi ini dipengaruhi oleh spesifikasinya implementasi dan demografi klien (penggunaan seluler vs desktop, ketersediaan aplikasi asli), namun mereka memberikan wawasan berharga tentang penggunaan transport biasa:

Wawasan Utama:

Autentikator platform mendominasi: Sebagian besar kunci sandi menggunakan transport internal, sering dikombinasikan dengan hybrid untuk dukungan autentikasi lintas perangkat. Ini mencerminkan fokus konsumen pada autentikator platform (iCloud Keychain, Google Password Manager).

Array kosong umum terjadi: Aplikasi asli iOS sering kali mengembalikan array transport yang kosong untuk autentikator platform, yang mewakili sebagian besar kredensial produksi. Seperti yang dibahas di bagian 2.2.3, hal ini menunjukkan informasi transport yang tidak tersedia, bukan merupakan dukungan transport yang komprehensif.

Kunci keamanan jarang terjadi: Kunci keamanan perangkat keras (usb, nfc) mewakili sebagian kecil dari kunci sandi produksi, menunjukkan penggunaan utamanya dalam skenario perusahaan atau keamanan tinggi daripada aplikasi konsumen.

Ada variasi urutan: Urutan transport dalam array (["internal", "hybrid"] vs ["hybrid", "internal"]) bervariasi menurut platform dan implementasi autentikator tetapi tidak memiliki perbedaan fungsi - keduanya menunjukkan dukungan untuk metode transport yang sama.

Terminologi lama: Pengidentifikasi transport cable muncul sesekali pada implementasi lama dan identik dengan hybrid (caBLE = cloud-assisted Bluetooth Low Energy, nama asli untuk transport hybrid).

Distribusi ini memperkuat pentingnya menangani transport internal dan hybrid dengan benar, karena mereka menyumbang sebagian besar implementasi kunci sandi dunia nyata.

Ketersediaan transport menunjukkan apa yang dilaporkan oleh autentikator, bukan apakah alur yang dihasilkan akan selesai. Analisis penyelesaian autentikasi lintas perangkat Corbado Passkey Benchmark 2026 mengukur penyelesaian transport hybrid pada Q1 2026 sebesar 60–78% di web Windows dan 66–86% di web macOS secara keseluruhan, terbagi menjadi 79–98% (Win) / 83–98% (macOS) untuk dorongan perangkat yang sama (same-device nudges) dibandingkan dengan 52–67% (Win) / 59–76% (macOS) untuk alur yang mendahulukan pengidentifikasi. Perlakukan hybrid sebagai transport dengan biaya tertinggi dalam logika perutean (routing logic) dan lebih utamakan alur yang menjaga pengguna tetap berada di perangkat yang menyimpan kredensial tersebut.

Autentikator yang sama sering melaporkan pola transport yang berbeda berdasarkan platform, versi, dan konteks implementasi. Variasi ini normal dan wajar:

iCloud Keychain menunjukkan tiga pola:

• ["internal", "hybrid"] - Paling umum, biasanya dari browser web
• [] (array kosong) - Sangat umum, dari aplikasi asli iOS
• ["hybrid", "internal"] - Kurang umum, variasi urutan
• Hanya ["internal"] atau ["hybrid"] - Kasus tepi (edge cases) yang jarang

Google Password Manager menunjukkan paling banyak variasi:

• ["hybrid", "internal"] - Pola paling umum
• ["internal", "hybrid"] - Urutan alternatif yang umum
• ["internal", "cable"] - Implementasi lama (cable = istilah lama untuk hybrid)
• [] (array kosong) - Dari konteks aplikasi asli tertentu
• Transport tunggal (jarang terjadi)

Windows Hello yang paling konsisten:

• ["internal"] - Pola dominan (terikat perangkat berdasarkan desain)

Pengelola kata sandi seperti 1Password, Bitwarden, Dashlane, dan LastPass semuanya menunjukkan pola variasi yang serupa:

• Urutan ["internal", "hybrid"] maupun ["hybrid", "internal"]
• Array kosong [] dari konteks aplikasi asli
• Terkadang hanya ["internal"]

Samsung Pass (ekosistem Android) terutama menggunakan:

• ["hybrid", "internal"] dan ["internal", "hybrid"] - Kedua urutan ini umum

Perbedaan platform: Autentikator yang sama berperilaku berbeda di web vs asli, iOS vs Android, atau Windows vs macOS.

Evolusi versi: Pelaporan transport telah berkembang seiring waktu. Versi yang lebih lama mungkin menggunakan cable daripada hybrid, atau melaporkan kombinasi yang berbeda.

Pilihan implementasi: Beberapa autentikator memprioritaskan internal terlebih dahulu, yang lain hybrid. Urutannya tidak memiliki dampak fungsional tetapi bervariasi menurut implementasi.

Sensitivitas konteks: Aplikasi asli, terutama di iOS, sering menerima array kosong bahkan dari autentikator yang melaporkan transport penuh dalam konteks web.

Poin Penting: Jangan berasumsi bahwa array transport akan selalu konsisten untuk autentikator tertentu. Rancang implementasi Anda untuk menangani semua variasi dengan anggun (gracefully), dengan fokus pada keberadaan transport tertentu alih-alih pada pencocokan array yang sama persis.

Pengembang menghadapi pilihan: mengikuti spesifikasi dengan ketat, atau mengoptimalkan transport internal dan hybrid untuk pengalaman pengguna. Setiap pendekatan memiliki kelebihan dan kekurangan.

Pendekatan ini selaras dengan spesifikasi WebAuthn: gunakan transport persis seperti yang diberikan oleh autentikator selama pendaftaran kredensial, dan kirim kembali tanpa perubahan selama autentikasi.

Implementasi: Saat kunci sandi dibuat, pertahankan array transports dari respons autentikator. Selama autentikasi, sertakan transport persis ini di dalam daftar allowCredentials:

{
    "allowCredentials": [
        {
            "id": "credential-id-base64",
            "type": "public-key",
            "transports": ["internal", "hybrid"]
        }
    ]
}

Kelebihan:

• Kepatuhan pada spesifikasi: Mengikuti standar WebAuthn secara persis, memastikan kompatibilitas dengan pembaruan platform di masa mendatang
• Keandalan kunci keamanan: Berfungsi sempurna untuk kunci keamanan perangkat keras (YubiKeys, dll.) yang selalu memberikan informasi transport secara akurat
• Mencegah opsi yang tidak valid: Menghindari penawaran metode autentikasi yang benar-benar tidak didukung—misalnya, tidak akan memicu kode QR untuk kredensial Windows Hello

Kekurangan:

• Perilaku array kosong iOS: Autentikator platform di iOS mengembalikan transport kosong, yang menunjukkan informasi transport tidak tersedia—platform mungkin menginterpretasikan hal ini secara berbeda saat menentukan opsi autentikasi mana yang akan ditampilkan
• Dapat menampilkan opsi yang tidak diinginkan: Dapat menampilkan opsi kunci keamanan (USB, NFC) dalam aplikasi konsumen yang mana hal tersebut tidak diharapkan
• Pengalaman pengguna yang tidak konsisten: Berbagai platform menawarkan opsi autentikasi yang berbeda untuk akun yang sama

Paling cocok untuk: Aplikasi yang memprioritaskan kepatuhan standar, lingkungan perusahaan dengan jenis autentikator yang beragam.

Pendekatan ini memprioritaskan pengalaman pengguna (UX) dengan secara selektif memodifikasi transport internal dan hybrid berdasarkan tujuan pengoptimalan tertentu. Daripada menggunakan satu aturan yang mencakup semua, pertimbangkan skenario pengoptimalan yang umum berikut ini:

Masalah: Autentikator platform iOS mengembalikan array transport yang kosong. Ketika dibiarkan kosong atau diisi oleh backend, pengguna mungkin melihat perintah kunci keamanan (USB, NFC) bersama opsi platform, menciptakan kebingungan dalam aplikasi konsumen.

Solusi: Secara eksplisit mengatur transport ke ["hybrid", "internal"] untuk autentikator platform iOS. Ini memastikan hanya autentikasi platform dan alur lintas perangkat yang ditawarkan, menyembunyikan opsi kunci keamanan.

// Saat menyimpan kredensial autentikator platform iOS
if (platform === "iOS" && authenticatorAttachment === "platform") {
    transports = ["hybrid", "internal"];
}

Hasil: UI autentikasi yang bersih tanpa perintah kunci keamanan untuk kunci sandi yang dibuat oleh iOS.

Masalah: Saat melakukan autentikasi di perangkat seluler, menampilkan kode QR untuk autentikasi lintas perangkat dapat menciptakan UX yang buruk—pengguna sudah berada di perangkat seluler dengan kunci sandi mereka yang tersedia.

Solusi: Hapus transport hybrid ketika pengguna mengautentikasi dari perangkat seluler, hanya menyisakan ["internal"].

// Saat membangun allowCredentials untuk autentikasi
const transports = isMobileDevice
    ? credentials.transports.filter((t) => t !== "hybrid")
    : credentials.transports;

Hasil: Pengguna seluler hanya melihat opsi autentikasi langsung tanpa perintah kode QR yang tidak perlu.

⚠️ Perhatian: Manipulasi transport tidak selalu menghasilkan hasil yang konsisten di seluruh platform. Pengujian ekstensif menunjukkan bahwa kombinasi browser dan OS menangani transport secara berbeda:

• Beberapa platform menampilkan kode QR bahkan ketika hybrid dikecualikan dari transport
• Platform lain menyembunyikan kode QR bahkan ketika hybrid disertakan
• Perilaku bervariasi secara signifikan antara Chrome, Edge, Safari, dan Firefox di Windows, macOS, dan iOS

Risiko jalan buntu (deadends): Pemfilteran transport yang terlalu ketat dapat membuat jalan buntu autentikasi yang mengakibatkan pengguna tidak dapat login sama sekali. Misalnya, menghapus hybrid dapat mencegah skenario autentikasi lintas perangkat yang sah ketika pengguna perlu melakukan autentikasi dari perangkat pinjaman. Selalu sediakan metode autentikasi cadangan dan uji secara menyeluruh pada semua platform target Anda sebelum menerapkan pengoptimalan transport.

Ini adalah petunjuk pengoptimalan: WebAuthn menyediakan mekanisme lain untuk mengoptimalkan UX autentikasi di luar manipulasi transport—seperti petunjuk (hints).

Perilaku transport tidak dapat diprediksi: Autentikasi lintas perangkat (CDA) melalui transport hybrid menunjukkan perilaku tidak konsisten di berbagai kombinasi browser dan OS. Pengujian di dunia nyata menunjukkan bahwa nilai transport tidak menjamin perilaku UI tertentu—platform menafsirkan dan menangani transport secara berbeda, yang mengarah pada hasil yang tidak terduga.

Kompleksitas spesifik platform: Saat mengontrol transport secara eksplisit, Anda harus mempertimbangkan perbedaan platform:

• iOS: Mengirim array kosong untuk autentikator platform; memerlukan pengisian
• Windows Hello: Harus tetap ["internal"] saja; menambahkan hybrid memicu kode QR yang tidak diinginkan
• Web & Android: Umumnya menyediakan informasi transport yang akurat
• Variasi CDA: Perintah kode QR mungkin muncul atau hilang terlepas dari keberadaan hybrid dalam array transport

Diperlukan pemahaman dari ujung ke ujung (end-to-end): Mengontrol transport secara eksplisit berarti bertanggung jawab atas seluruh alur. Anda harus memahami bagaimana setiap kombinasi transport berperilaku di semua platform target Anda dan mengujinya secara menyeluruh. Manipulasi transport dapat menyebabkan jalan buntu autentikasi di mana tidak ada jalur autentikasi valid yang tersedia bagi pengguna.

Kelebihan:

• UX yang disesuaikan: Mengontrol opsi autentikasi mana yang tepatnya dilihat oleh pengguna dalam konteks tertentu
• Menyelesaikan masalah array kosong iOS: Mendefinisikan secara eksplisit transport di mana iOS tidak menyediakannya
• Pengoptimalan sadar konteks: Menyesuaikan UI autentikasi berdasarkan jenis perangkat

Kekurangan:

• Perilaku yang tidak dapat diprediksi: Manipulasi transport tidak menjamin perilaku UI yang konsisten—pengujian ekstensif menunjukkan platform menafsirkan transport secara berbeda, terkadang menampilkan atau menyembunyikan opsi terlepas dari nilai transport
• Risiko jalan buntu autentikasi: Pemfilteran transport yang terlalu ketat dapat mencegah pengguna dari mengautentikasi sama sekali, terutama dalam skenario lintas perangkat
• Menyimpang dari spesifikasi: Menjauh dari rekomendasi spesifikasi, berpotensi menyebabkan masalah dengan perubahan platform di masa mendatang
• Beban pemeliharaan: Membutuhkan logika dan pembaruan spesifik platform yang berkelanjutan saat platform berevolusi
• Kompleksitas: Harus menangani array kosong iOS, kendala Windows Hello, dan keanehan (quirks) platform lainnya secara manual
• Overhead pengujian: Setiap aturan pengoptimalan memerlukan verifikasi di semua kombinasi platform

Paling cocok untuk: Aplikasi konsumen dengan persyaratan UX tertentu, tim dengan sumber daya untuk memelihara logika spesifik platform, skenario yang memprioritaskan alur autentikasi yang disederhanakan dibandingkan dengan kepatuhan spesifikasi yang ketat.

Penanganan transport WebAuthn tidak ada dalam isolasi—ini adalah salah satu bagian dari strategi penerapan kunci sandi Anda secara keseluruhan. Dua pendekatan umum muncul dalam penerapan produksi, masing-masing dengan implikasi yang berbeda untuk penggunaan transport internal dan hybrid.

Pendekatan ini memprioritaskan fleksibilitas dan kepatuhan standar, yang memungkinkan pengguna untuk melakukan autentikasi dengan autentikator yang kompatibel apa pun.

Karakteristik Implementasi:

• UI Autentikasi: Tombol kunci sandi muncul bersama opsi login yang sudah ada (nama pengguna/kata sandi)
• allowCredentials: Diatur ke array kosong [], memungkinkan kunci apa saja untuk cocok
• Jenis autentikator: Kunci keamanan, autentikasi lintas perangkat (kode QR), autentikator platform semuanya didukung
• Persyaratan aplikasi asli: Harus mendukung semua metode autentikasi, termasuk kunci keamanan
• preferImmediatelyAvailableCredentials: Tidak dapat digunakan, karena hal itu mengecualikan kunci keamanan dan login kode QR menurut definisinya
• Penanganan transport: Harus mengakomodasi semua jenis transport, termasuk transport kunci keamanan (usb, nfc, ble)

Implikasi Transport:

Dengan allowCredentials yang kosong, transport menjadi kurang penting selama autentikasi—platform menampilkan semua opsi yang tersedia. Namun, ini berarti pengguna mungkin melihat perintah kunci keamanan, kode QR, dan opsi platform secara bersamaan, yang dapat menciptakan kelumpuhan pengambilan keputusan di aplikasi konsumen.

Paling cocok untuk: Lingkungan perusahaan, aplikasi dengan basis pengguna yang beragam yang membutuhkan dukungan kunci keamanan, skenario yang memprioritaskan fleksibilitas autentikasi maksimum.

Pendekatan ini dioptimalkan untuk UX konsumen dengan membatasi pembuatan kunci sandi ke autentikator platform dan menggunakan alur yang mendahulukan pengidentifikasi (identifier-first).

Karakteristik Implementasi:

• Pembuatan kunci sandi: Dorongan yang diinisiasi pengguna (perintah pasca-login, alur pembuatan otomatis) menggunakan authenticatorAttachment: "platform" untuk fokus pada autentikator yang tersedia dengan segera
• Dukungan kunci keamanan: Tersedia melalui pengaturan akun web tanpa pembatasan authenticatorAttachment, memungkinkan pengguna pro (power users) untuk memilih autentikator mana pun termasuk kunci keamanan
• Alur autentikasi: Mendahulukan pengidentifikasi (Identifier-first)—pengguna memasukkan email/nama pengguna sebelum autentikasi
• allowCredentials: Diisi dengan kredensial spesifik pengguna (tidak kosong) setelah pengidentifikasi diketahui
• Jenis autentikator: Autentikator platform dan autentikasi lintas perangkat diprioritaskan; kunci keamanan didukung tetapi tidak dipromosikan dalam alur utama
• Optimalisasi aplikasi asli: Menggunakan preferImmediatelyAvailableCredentials untuk autentikasi yang diam (silent) dan instan tanpa perintah untuk kunci keamanan atau kode QR
• Autentikasi lintas perangkat: Tersedia di web; sengaja dikecualikan dalam aplikasi asli ketika menggunakan preferImmediatelyAvailableCredentials (pengguna biasanya melakukan autentikasi pada perangkat di mana kunci sandi mereka berada)
• Penanganan transport: Fokus utama pada transport internal dan hybrid

Implikasi Transport:

Karena allowCredentials berisi kredensial spesifik beserta transportnya, penanganan transport menjadi krusial untuk mengoptimalkan pengalaman autentikasi.

Realitas Kunci Keamanan: Kunci keamanan mewakili sebagian kecil dari penggunaan kunci sandi dalam peluncuran konsumen berskala besar—terutama para pengguna tingkat lanjut atau pengguna yang memiliki persyaratan keamanan tertentu. Pendekatan yang disesuaikan bagi konsumen mengakui kenyataan ini dengan mendukung kunci keamanan tanpa mengoptimalkan alur utama mereka.

Strategi Pembuatan Dua Tingkat: Implementasi dapat menyeimbangkan kompatibilitas kunci keamanan dengan UX konsumen yang dioptimalkan melalui jalur pembuatan ganda:

• Dorongan dan perintah pengguna: Perintah pasca-login dan alur pembuatan otomatis menggunakan authenticatorAttachment: "platform", yang memandu pengguna menuju kunci sandi yang segera tersedia yang memiliki tingkat keberhasilan tinggi
• Pengaturan akun web: Menawarkan pembuatan tanpa authenticatorAttachment, memungkinkan pengguna tingkat lanjut untuk memilih kunci keamanan, pengelola kata sandi pihak ketiga, atau autentikator apa pun yang tersedia

Pola ini muncul dalam implementasi besar: kunci keamanan didukung dan berfungsi melalui pengaturan, tetapi dorongan yang menghadap pengguna mengoptimalkan kasus penggunaan yang dominan—autentikator platform yang menyediakan autentikasi diam yang instan.

Paling cocok untuk: Aplikasi konsumen, aplikasi seluler asli, skenario yang memprioritaskan UX yang efisien (streamlined) di atas fleksibilitas autentikator, platform tempat alur yang mendahulukan pengidentifikasi sudah ada.

Untuk platform yang sudah membocorkan keberadaan akun atau menggunakan alur yang mendahulukan pengidentifikasi (pengguna memasukkan email sebelum melihat opsi masuk), pendekatan yang disesuaikan konsumen selaras secara alami. Setelah pengguna memberikan pengidentifikasinya:

1. Backend meminta kunci sandi yang ada
2. Mengembalikan allowCredentials dengan kredensial spesifik dan transport mereka
3. Platform dapat mengoptimalkan UI autentikasi berdasarkan transport
4. Tidak ada risiko tambahan terkait pencacahan akun (pengidentifikasi sudah disediakan)

Dalam skenario ini, transport dapat menjadi alat pengoptimalan alih-alih masalah keamanan. Anda dapat menyesuaikan opsi autentikasi berdasarkan konteks perangkat (seluler vs desktop) dan kemampuan kredensial.

Rekomendasi: Untuk platform yang sudah menggunakan alur mendahulukan pengidentifikasi atau di mana pencacahan akun tidak menjadi masalah, pendekatan yang disesuaikan konsumen dengan penanganan transport eksplisit memberikan UX yang unggul, terutama di aplikasi seluler asli di mana preferImmediatelyAvailableCredentials memungkinkan autentikasi biometrik yang mulus.

Terlepas dari pendekatan apa yang Anda pilih untuk menangani transport internal dan hybrid, ikuti praktik ini untuk meminimalkan masalah:

Pertahankan Transport Selama Pendaftaran: Selalu simpan array transports dari respons autentikator di samping ID kredensial dan kunci publik. Data ini sangat penting untuk alur autentikasi.

Tangani Array Kosong dengan Anggun: Saat menerima array transport kosong dari autentikator platform iOS:

• Sesuai spesifikasi: Biarkan kosong atau hilangkan properti transport—menunjukkan bahwa informasi transport tidak tersedia; platform akan menentukan opsi yang tersedia
• Pendekatan pengoptimalan: Isi dengan ["internal", "hybrid"] untuk mengontrol opsi autentikasi mana yang ditampilkan

Strategi Transport Web vs Asli (Native): Bedakan penanganan transport berdasarkan konteks:

• Autentikasi web: Sertakan semua transport, memungkinkan dukungan autentikator yang lebih luas termasuk kunci keamanan melalui USB/NFC
• Autentikasi aplikasi asli: Gunakan preferImmediatelyAvailableCredentials untuk autentikasi diam (silent); transport dikirim seperti yang disimpan
• Halaman pengaturan/manajemen: Mendukung semua jenis autentikator untuk pengguna tingkat lanjut (power users)

Tangani Autentikasi Kunci Keamanan: Ketika pengguna memiliki kunci keamanan yang terdaftar:

• Web: Deteksi transport kunci keamanan di kredensial yang disimpan dan pastikan alur autentikasi dapat mengakomodasinya
• Aplikasi asli: Pertimbangkan untuk memberikan metode autentikasi cadangan atau mengarahkan pengguna ke web untuk autentikasi kunci keamanan
• Pendekatan hybrid: Aplikasi asli mengoptimalkan autentikator platform sementara web mendukung fleksibilitas autentikator secara penuh

Uji Lintas Semua Platform Target: Buat matriks pengujian yang mencakup semua kombinasi:

• Pendaftaran: Web, iOS Asli, Android Asli
• Autentikasi: Web, iOS Asli, Android Asli
• Verifikasi autentikasi diam bekerja dengan preferImmediatelyAvailableCredentials
• Konfirmasikan kunci keamanan berfungsi dalam alur pengaturan tanpa authenticatorAttachment
• Validasi kode QR hanya muncul dalam konteks yang tepat

Pahami Semantik Transport: Kenali perbedaan antara nilai transport yang kosong dan hilang:

• Array transport kosong []: Menunjukkan informasi transport tidak tersedia atau disembunyikan untuk privasi. Agen pengguna mungkin memberikan urutan kosong ketika mereka tidak bisa atau memilih untuk tidak melaporkan kemampuan transport. Hal ini tidak sama dengan "semua transport didukung"—perlakukan hal itu sebagai petunjuk di mana informasinya tidak tersedia.
• Properti transports yang hilang: Ketika transports dihilangkan dari deskriptor kredensial, agen pengguna menentukan metode autentikasi yang tersedia berdasarkan faktor lainnya. Konteks itu penting: dalam respons pendaftaran vs opsi permintaan autentikasi, implikasinya berbeda.
• Petunjuk (hints) transport: Sesuai dengan spesifikasi, transport harus diperlakukan sebagai petunjuk untuk membantu agen pengguna mengoptimalkan antarmuka autentikasi, bukan sebagai jaminan akan kapabilitas secara otoritatif.

Pantau Perubahan Platform: Implementasi WebAuthn terus berkembang. Apple, Google, dan Microsoft secara teratur memperbarui perilaku autentikator mereka. Tetap terinformasi tentang perubahan yang dapat memengaruhi penanganan transport.

Transport WebAuthn—terutama transport internal dan hybrid—adalah detail teknis dengan dampak praktis yang signifikan pada autentikasi lintas perangkat. Strategi penanganan transport Anda harus sejalan dengan pendekatan penerapan kunci sandi yang lebih luas dan platform target Anda.

Keputusan Transport Berada Dalam Strategi yang Lebih Luas: Bagaimana Anda menangani transport bergantung pada apakah Anda membangun untuk fleksibilitas maksimal (allowCredentials kosong) atau UX konsumen (mendahulukan pengidentifikasi dengan kredensial spesifik). Yang terakhir ini membuat transport menjadi penting untuk pengoptimalan.

Perbedaan Platform Membutuhkan Penanganan: Web dan Android menyediakan informasi transport yang dapat diandalkan, sedangkan autentikator platform iOS mengembalikan array kosong. Windows Hello hanya mengirimkan ["internal"]. Memahami perbedaan-perbedaan ini sangat penting untuk peluncuran di lingkungan produksi.

Dua Pendekatan Transport yang Valid: Sesuai dengan spesifikasi (memercayai transport dari autentikator) berfungsi dengan baik untuk perusahaan dan skenario dengan fleksibilitas yang maksimum. Kontrol eksplisit (mengoptimalkan transport) cocok untuk aplikasi konsumen dengan alur yang mendahulukan pengidentifikasi dan aplikasi seluler asli.

Mendahulukan Pengidentifikasi Memungkinkan Pengoptimalan Transport: Ketika pengguna memberikan pengidentifikasinya terlebih dahulu, penanganan transport menjadi alat UX yang kuat. Anda dapat mencegah kode QR yang tidak diinginkan di perangkat seluler, menyembunyikan opsi kunci keamanan, dan merampingkan (streamline) autentikasi—tanpa kekhawatiran terkait pencacahan akun tambahan.

Untuk Perusahaan / Fleksibilitas Maksimum:

• Gunakan allowCredentials yang kosong untuk mendukung semua jenis autentikator
• Percayakan transport yang disediakan oleh autentikator
• Terima bahwa pengguna melihat lebih banyak opsi autentikasi
• Implementasi yang lebih sederhana, kompatibilitas yang lebih luas

Untuk Aplikasi Konsumen / Aplikasi Asli (Native):

• Implementasikan alur autentikasi yang mendahulukan pengidentifikasi
• Dorongan pengguna (pasca-login, perintah otomatis): Gunakan authenticatorAttachment: "platform" untuk autentikasi langsung dengan keberhasilan tinggi
• Pengaturan akun web: Mengizinkan pembuatan tanpa authenticatorAttachment bagi pengguna pro (power users) yang membutuhkan kunci keamanan
• Gunakan allowCredentials dengan kredensial spesifik dan transport yang dioptimalkan
• Aplikasi asli: Aktifkan preferImmediatelyAvailableCredentials untuk autentikasi diam (silent)
• Isi array kosong iOS dengan ["hybrid", "internal"]
• Autentikasi web: Mendukung semua transport termasuk kunci keamanan
• Filter hybrid di perangkat seluler untuk mencegah kode QR di mana yang sesuai
• UX (Pengalaman Pengguna) yang superior dengan opsi autentikasi yang efisien sambil mempertahankan kompatibilitas

Untuk Platform yang Sudah Memiliki Alur Mendahulukan Pengidentifikasi (Identifier-First):

• Pencacahan (Enumeration) akun sudah bukan masalah
• Pendekatan yang disesuaikan untuk konsumen selaras secara alami dengan UX yang ada
• Pengoptimalan transport memberikan manfaat UX secara langsung
• Pendekatan yang direkomendasikan untuk sebagian besar aplikasi konsumen

Mulai dari yang sesuai spesifikasi, kemudian optimalkan berdasarkan strategi Anda:

1. Simpan transport sama persis seperti yang diterima selama pendaftaran
2. Putuskan strategi Anda secara keseluruhan (fleksibilitas maksimum vs. yang disesuaikan untuk konsumen)
3. Jika disesuaikan untuk konsumen: implementasikan alur yang mendahulukan pengidentifikasi dan optimalkan transport
4. Tangani array kosong iOS dengan tepat untuk strategi pilihan Anda
5. Lakukan pengujian secara menyeluruh di platform Web, iOS Asli, dan Android Asli

Lanskap WebAuthn terus berkembang. Vendor platform secara rutin memperbarui implementasinya, dan spesifikasi seperti WebAuthn Level 3 memperkenalkan berbagai kapabilitas baru. Membangun sistem yang fleksibel dan menyelaraskan penanganan transport dengan strategi autentikasi yang lebih luas akan memastikan bahwa implementasi kunci sandi Anda tetap tangguh (robust) dan memberikan pengalaman pengguna yang sangat baik di saat ekosistemnya semakin matang.

Tentang Corbado

Corbado adalah Passkey 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 →

iOS AuthenticationServices menyembunyikan informasi transport untuk autentikator platform seperti iCloud Keychain, dengan mengembalikan array kosong sesuai dengan ketentuan privasi spesifikasi WebAuthn. Kunci keamanan di iOS tetap menyediakan data transport seperti ["usb"] atau ["nfc"]. Pihak yang mengandalkan (relying parties) harus memperlakukan semua transport sebagai petunjuk daripada jaminan kemampuan yang otoritatif.

cable adalah terminologi lama yang bersinonim dengan hybrid, singkatan dari caBLE (cloud-assisted Bluetooth Low Energy). Keduanya menjelaskan autentikasi lintas perangkat seperti memindai kode QR untuk mengautentikasi sesi desktop menggunakan ponsel. hybrid adalah istilah saat ini yang diperkenalkan di WebAuthn Level 3 dan harus digunakan dalam implementasi baru.

Untuk aplikasi konsumen yang menggunakan alur yang mendahulukan pengidentifikasi, secara eksplisit atur transport ke ["hybrid", "internal"] untuk autentikator platform iOS yang mengembalikan array kosong selama pendaftaran. Ini mencegah perintah kunci keamanan USB dan NFC muncul di UI autentikasi. Alternatif yang sesuai spesifikasi adalah membiarkan array tetap kosong atau menghilangkan properti transports sama sekali.

Menghapus transport hybrid pada ponsel mencegah munculnya perintah kode QR ketika pengguna sudah berada di perangkat tempat kunci sandi mereka berada. Namun, manipulasi transport memberikan hasil yang tidak konsisten: beberapa platform menampilkan kode QR bahkan ketika hybrid dikecualikan, dan yang lain menyembunyikannya terlepas dari itu. Selalu lakukan pengujian di berbagai platform target dan berikan metode autentikasi cadangan untuk menghindari jalan buntu.

Array allowCredentials yang kosong mendukung semua jenis autentikator termasuk kunci keamanan dan autentikasi lintas perangkat, tetapi mengurangi relevansi transport dan mungkin menampilkan banyak opsi secara bersamaan kepada pengguna. Mengisinya dengan kredensial pengguna yang spesifik membuat penanganan transport menjadi penting untuk mengoptimalkan UI, memungkinkan alur yang mendahulukan pengidentifikasi untuk memfilter kode QR di perangkat seluler dan menyembunyikan perintah kunci keamanan dalam konteks konsumen.