Transport WebAuthn: Transport Internal dan Hybrid

Passkeys for Super Funds and Financial Institutions
Join our Webinar on 7th November to learn how Super Funds and Financial Institutions can implement passkeys

Join now

Catatan: Sesuai spesifikasi WebAuthn, transport yang kosong berarti semua transport didukung.

Saat mengimplementasikan passkey di berbagai platform, developer menghadapi keputusan penting:

• Bagaimana sebaiknya kita menangani transport WebAuthn, khususnya transport internal dan hybrid, untuk memastikan pengalaman autentikasi lintas perangkat yang optimal?

Jawabannya terletak pada pemahaman transport WebAuthn—sebuah detail teknis yang menentukan bagaimana authenticator berkomunikasi dengan relying party. Meskipun secara teori transport terlihat sederhana, implementasinya sangat bervariasi di berbagai browser web, aplikasi native iOS, dan native Android, terutama untuk penanganan transport internal dan hybrid.

Artikel ini mengulas cara kerja transport WebAuthn di berbagai platform dan menyajikan dua pendekatan berbeda untuk menangani transport internal dan hybrid—masing-masing dengan kelebihan dan kekurangannya.

Artikel ini membahas:

1. Transport WebAuthn: internal, hybrid, dan platform authenticator di 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 authenticator dan perangkat klien. Spesifikasi WebAuthn Level 3 mendefinisikan enam jenis transport:

usb: Digunakan oleh hardware security key yang terhubung melalui port USB, seperti YubiKeys atau token keamanan FIDO2 lainnya.

nfc: Memungkinkan komunikasi dengan authenticator melalui Near Field Communication, yang memungkinkan pengguna mengetuk security key atau perangkat berkemampuan NFC mereka.

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

smart-card: Digunakan untuk pembaca smart card, memungkinkan autentikasi melalui smart card.

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

internal: Authenticator 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 platform authenticator.

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

Penanganan transport berbeda secara signifikan di berbagai platform, yang menciptakan tantangan kompatibilitas yang dihadapi developer.

Browser menerima informasi transport dari authenticator dan menghormatinya selama alur autentikasi. Saat kita membuat passkey di Chrome, Safari, atau Edge, manajer kredensial browser menyediakan data transport yang bervariasi berdasarkan authenticator yang mendasarinya:

Platform authenticator: Windows Hello hanya menyediakan ["internal"], yang mencerminkan sifatnya yang terikat pada perangkat. Namun, ketika Chrome menggunakan Google Password Manager sebagai authenticator, ia menyediakan ["internal", "hybrid"] karena Google Password Manager mendukung autentikasi lintas perangkat melalui Ponsel Android.

Hardware security key: Menyediakan transport spesifik seperti ["usb", "nfc"] berdasarkan kemampuan aktualnya.

Manajer kredensial yang disinkronkan dengan cloud: 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 spesifik bergantung pada authenticator mana yang dipilih browser untuk penyimpanan kredensial.

Dokumentasi: Spesifikasi W3C WebAuthn

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

Dokumentasi: Android Credential Manager

iOS menyajikan situasi yang lebih kompleks. Framework AuthenticationServices Apple menangani transport secara berbeda tergantung pada jenis authenticator:

Platform authenticator (iCloud Keychain, diverifikasi melalui Face ID atau Touch ID): Sering kali mengembalikan array transport kosong selama pembuatan passkey. Ini tidak berarti passkey tidak memiliki kemampuan transport—ini hanya berarti iOS tidak melaporkannya secara eksplisit. Menurut standar WebAuthn, mengosongkan transport berarti transport apa pun dapat diterima, sehingga autentikasi hybrid akan tetap berfungsi.

Security key: Memberikan informasi transport (misalnya, ["usb"], ["nfc"]) saat digunakan dengan perangkat iOS, mengikuti pola yang diharapkan.

Dokumentasi: Apple AuthenticationServices

Developer dihadapkan pada pilihan: mengikuti spesifikasi secara ketat, atau mengoptimalkan transport internal dan hybrid untuk pengalaman pengguna. Setiap pendekatan memiliki kelebihan dan kekurangan.

Pendekatan ini sejalan dengan spesifikasi WebAuthn: gunakan transport persis seperti yang disediakan oleh authenticator selama registrasi kredensial, dan kirim kembali tanpa perubahan selama autentikasi.

Implementasi: Saat passkey dibuat, simpan array transports dari respons authenticator. Selama autentikasi, sertakan transport yang sama persis ini dalam daftar allowCredentials:

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

Keuntungan:

• Kepatuhan spesifikasi: Mengikuti standar WebAuthn secara tepat, memastikan kompatibilitas dengan pembaruan platform di masa mendatang.
• Keandalan security key: Bekerja sempurna untuk hardware security key (YubiKeys, dll.) yang selalu memberikan informasi transport yang akurat.
• Mencegah opsi yang tidak valid: Menghindari penawaran metode autentikasi yang sebenarnya tidak didukung—misalnya, tidak akan memicu QR code untuk kredensial Windows Hello.

Kekurangan:

• Perilaku array kosong iOS: Platform authenticator di iOS mengembalikan transport kosong, yang menurut spesifikasi berarti "transport apa pun"—ini mungkin menampilkan semua opsi autentikasi termasuk security key.
• Dapat menampilkan opsi yang tidak diinginkan: Dapat menyajikan opsi security key (USB, NFC) dalam aplikasi konsumen di mana hal itu tidak diharapkan.
• Pengalaman pengguna yang tidak konsisten: Platform yang berbeda menawarkan opsi autentikasi yang berbeda untuk akun yang sama.

Paling cocok untuk: Aplikasi yang memprioritaskan kepatuhan standar, lingkungan enterprise dengan beragam jenis authenticator.

Pendekatan ini memprioritaskan pengalaman pengguna dengan secara selektif memodifikasi transport internal dan hybrid berdasarkan tujuan optimisasi spesifik. Daripada aturan umum, pertimbangkan skenario optimisasi umum ini:

Masalah: Platform authenticator iOS mengembalikan array transport kosong. Jika dibiarkan kosong atau diisi oleh backend, pengguna mungkin melihat permintaan security key (USB, NFC) di samping opsi platform, yang menimbulkan kebingungan dalam aplikasi konsumen.

Solusi: Secara eksplisit atur transport ke ["hybrid", "internal"] untuk platform authenticator iOS. Ini memastikan hanya autentikasi platform dan alur lintas perangkat yang ditawarkan, menyembunyikan opsi security key.

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

Hasil: UI autentikasi yang bersih tanpa permintaan security key untuk passkey yang dibuat di iOS.

Masalah: Saat mengautentikasi di perangkat seluler, menampilkan QR code untuk autentikasi lintas perangkat menciptakan UX yang buruk—pengguna sudah berada di perangkat seluler dengan passkey mereka tersedia.

Solusi: Hapus transport hybrid saat 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 permintaan QR code 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 QR code bahkan ketika hybrid dikecualikan dari transport.
• Platform lain menyembunyikan QR code bahkan ketika hybrid disertakan.
• Perilaku bervariasi secara signifikan antara Chrome, Edge, Safari, dan Firefox di Windows, macOS, dan iOS.

Risiko jalan buntu: Pemfilteran transport yang terlalu ketat dapat menciptakan jalan buntu autentikasi di mana pengguna tidak dapat login sama sekali. Misalnya, menghapus hybrid dapat mencegah skenario autentikasi lintas perangkat yang sah di mana pengguna perlu mengautentikasi dari perangkat pinjaman. Selalu sediakan metode autentikasi cadangan dan uji secara menyeluruh di seluruh platform target Anda sebelum menerapkan optimisasi transport.

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

Perilaku transport tidak dapat diprediksi: Autentikasi lintas perangkat (CDA) melalui transport hybrid menunjukkan perilaku yang tidak konsisten di berbagai kombinasi browser dan OS. Pengujian 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, kita harus memperhitungkan perbedaan platform:

• iOS: Mengirim array kosong untuk platform authenticator; memerlukan pengisian.
• Windows Hello: Harus tetap ["internal"] saja; menambahkan hybrid memicu QR code yang tidak diinginkan.
• Web & Android: Umumnya memberikan informasi transport yang akurat.
• Variasi CDA: Permintaan QR code dapat muncul atau hilang terlepas dari keberadaan hybrid dalam array transport.

Memerlukan pemahaman end-to-end: Mengontrol transport secara eksplisit berarti mengambil tanggung jawab atas seluruh alur. Kita harus memahami bagaimana setiap kombinasi transport berperilaku di semua platform target dan mengujinya secara menyeluruh. Manipulasi transport dapat menciptakan jalan buntu autentikasi di mana tidak ada jalur autentikasi yang valid bagi pengguna.

Keuntungan:

• UX yang disesuaikan: Mengontrol dengan tepat opsi autentikasi mana yang dilihat pengguna dalam konteks tertentu.
• Memecahkan masalah array kosong iOS: Mendefinisikan transport secara eksplisit di mana iOS tidak menyediakannya.
• Optimisasi 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 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: Memerlukan logika dan pembaruan spesifik platform yang berkelanjutan seiring berkembangnya platform.
• Kompleksitas: Harus menangani array kosong iOS, batasan Windows Hello, dan keunikan platform lainnya secara manual.
• Beban pengujian: Setiap aturan optimisasi perlu diverifikasi di semua kombinasi platform.

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

Penanganan transport WebAuthn tidak berdiri sendiri—ini adalah salah satu bagian dari strategi implementasi passkey kita 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, memungkinkan pengguna untuk mengautentikasi dengan authenticator apa pun yang kompatibel.

Karakteristik Implementasi:

• UI Autentikasi: Tombol passkey muncul di samping opsi login yang ada (username/password).
• allowCredentials: Diatur ke array kosong [], memungkinkan kredensial apa pun untuk cocok.
• Jenis authenticator: Security key, autentikasi lintas perangkat (QR code), platform authenticator semuanya didukung.
• Persyaratan aplikasi native: Harus mendukung semua metode autentikasi, termasuk security key.
• preferImmediatelyAvailableCredentials: Tidak dapat digunakan, karena secara definisi mengecualikan security key dan login QR code.
• Penanganan transport: Harus mengakomodasi semua jenis transport, termasuk transport security key (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 permintaan security key, QR code, dan opsi platform secara bersamaan, yang dapat menciptakan kelumpuhan keputusan dalam aplikasi konsumen.

Paling cocok untuk: Lingkungan enterprise, aplikasi dengan basis pengguna yang beragam yang memerlukan dukungan security key, skenario yang memprioritaskan fleksibilitas autentikasi maksimal.

Pendekatan ini mengoptimalkan UX konsumen dengan membatasi pembuatan passkey ke platform authenticator dan menggunakan alur identifier-first.

Karakteristik Implementasi:

• Pembuatan passkey: Hanya platform authenticator yang diizinkan melalui authenticatorAttachment: "platform".
• Alur autentikasi: Identifier-first—pengguna memasukkan email/username sebelum autentikasi.
• allowCredentials: Diisi dengan kredensial spesifik pengguna (tidak kosong) setelah identifier diketahui.
• Jenis authenticator: Platform authenticator dan autentikasi lintas perangkat; security key biasanya dikecualikan.
• Optimisasi aplikasi native: Dapat menggunakan preferImmediatelyAvailableCredentials, yang secara definisi mengecualikan security key dan autentikasi lintas perangkat.
• Autentikasi lintas perangkat: Tersedia di web; tidak tersedia saat menggunakan preferImmediatelyAvailableCredentials di aplikasi native, tetapi skenario ini jarang terjadi (pengguna biasanya memiliki passkey di perangkat yang mereka gunakan).
• Penanganan transport: Terfokus pada transport internal dan hybrid saja.

Implikasi Transport:

Karena allowCredentials berisi kredensial spesifik dengan transportnya, penanganan transport menjadi krusial.

Paling cocok untuk: Aplikasi konsumen, aplikasi seluler native, skenario yang memprioritaskan UX yang efisien daripada fleksibilitas authenticator, platform di mana alur identifier-first sudah ada.

Untuk platform yang sudah membocorkan keberadaan akun atau menggunakan alur identifier-first (pengguna memasukkan email sebelum melihat opsi login), pendekatan yang disesuaikan untuk konsumen selaras secara alami. Setelah pengguna memberikan identifier mereka:

1. Backend menanyakan passkey yang ada.
2. Mengembalikan allowCredentials dengan kredensial spesifik dan transportnya.
3. Platform dapat mengoptimalkan UI autentikasi berdasarkan transport.
4. Tidak ada risiko account enumeration tambahan (identifier sudah disediakan).

Dalam skenario ini, transport dapat menjadi alat optimisasi daripada masalah keamanan. Kita dapat menyesuaikan opsi autentikasi berdasarkan konteks perangkat (seluler vs. desktop) dan kemampuan kredensial.

Rekomendasi: Untuk platform yang sudah menggunakan alur identifier-first atau di mana account enumeration tidak menjadi perhatian, pendekatan yang disesuaikan untuk konsumen dengan penanganan transport eksplisit memberikan UX yang superior, terutama di aplikasi seluler native di mana preferImmediatelyAvailableCredentials memungkinkan autentikasi biometrik yang mulus.

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

Simpan Transport Selama Registrasi: Selalu simpan array transports dari respons authenticator bersama dengan ID kredensial dan kunci publik. Data ini penting untuk alur autentikasi.

Tangani Array Kosong dengan Baik: Saat menerima array transport kosong dari platform authenticator iOS:

• Sesuai spesifikasi: Biarkan kosong atau hilangkan properti transport—berarti "transport apa pun" dapat diterima.
• Pendekatan optimisasi: Isi dengan ["internal", "hybrid"] untuk mengontrol opsi autentikasi mana yang ditampilkan.

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

• Registrasi: Web, iOS Native, Android Native
• Autentikasi: Web, iOS Native, Android Native
• Verifikasi QR code muncul saat diharapkan dan disembunyikan saat tidak sesuai.

Pahami Array Kosong vs. Properti yang Hilang: Baik array transport kosong [] maupun properti transport yang hilang biasanya diperlakukan sebagai "transport apa pun dapat diterima" menurut spesifikasi. Namun, detail implementasi bervariasi di berbagai platform.

Pantau Perubahan Platform: Implementasi WebAuthn terus berkembang. Apple, Google, dan Microsoft secara teratur memperbarui perilaku authenticator mereka. Tetap terinformasi tentang perubahan yang mungkin 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 kita harus selaras dengan pendekatan implementasi passkey yang lebih luas dan platform target.

Keputusan Transport Berada dalam Strategi yang Lebih Luas: Cara kita menangani transport bergantung pada apakah kita membangun untuk fleksibilitas maksimal (kosongkan allowCredentials) atau UX konsumen (identifier-first dengan kredensial spesifik). Yang terakhir membuat transport menjadi krusial untuk optimisasi.

Perbedaan Platform Memerlukan Penanganan: Web dan Android menyediakan informasi transport yang andal, sementara platform authenticator iOS mengembalikan array kosong. Windows Hello hanya mengirim ["internal"]. Memahami perbedaan ini sangat penting untuk penerapan produksi.

Dua Pendekatan Transport yang Valid: Sesuai spesifikasi (percaya transport authenticator) bekerja dengan baik untuk skenario enterprise dan fleksibilitas maksimal. Kontrol eksplisit (optimalkan transport) cocok untuk aplikasi konsumen dengan alur identifier-first dan aplikasi seluler native.

Identifier-First Memungkinkan Optimisasi Transport: Saat pengguna memberikan identifier mereka terlebih dahulu, penanganan transport menjadi alat UX yang kuat. Kita dapat mencegah QR code yang tidak diinginkan di seluler, menyembunyikan opsi security key, dan menyederhanakan autentikasi—tanpa kekhawatiran account enumeration tambahan.

Untuk Enterprise / Fleksibilitas Maksimal:

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

Untuk Aplikasi Konsumen / Aplikasi Native:

• Terapkan alur autentikasi identifier-first.
• Batasi ke platform authenticator (authenticatorAttachment: "platform").
• Gunakan allowCredentials dengan kredensial spesifik dan transport yang dioptimalkan.
• Aktifkan preferImmediatelyAvailableCredentials di aplikasi native.
• Isi array kosong iOS dengan ["hybrid", "internal"].
• Filter hybrid di perangkat seluler untuk mencegah QR code.
• UX superior dengan opsi autentikasi yang efisien.

Untuk Platform yang Sudah Menggunakan Alur Identifier-First:

• Account enumeration sudah tidak menjadi masalah.
• Pendekatan yang disesuaikan untuk konsumen selaras secara alami dengan UX yang ada.
• Optimisasi transport memberikan manfaat UX langsung.
• Pendekatan yang direkomendasikan untuk sebagian besar aplikasi konsumen.

Mulai dengan yang sesuai spesifikasi, lalu optimalkan berdasarkan strategi Anda:

1. Simpan transport persis seperti yang diterima selama registrasi.
2. Tentukan strategi keseluruhan Anda (fleksibilitas maksimal vs. disesuaikan untuk konsumen).
3. Jika disesuaikan untuk konsumen: terapkan alur identifier-first dan optimalkan transport.
4. Tangani array kosong iOS dengan tepat untuk strategi yang Anda pilih.
5. Uji secara menyeluruh di platform Web, iOS Native, dan Android Native.

Lanskap WebAuthn terus berkembang. Vendor platform secara teratur memperbarui implementasi mereka, dan spesifikasi seperti WebAuthn Level 3 memperkenalkan kemampuan baru. Membangun sistem yang fleksibel yang menyelaraskan penanganan transport dengan strategi autentikasi yang lebih luas memastikan implementasi passkey Anda tetap kuat dan memberikan pengalaman pengguna yang sangat baik seiring dengan matangnya ekosistem.