Passkey Aplikasi Native: Implementasi Native vs. WebView

Artikel ini menjelaskan cara mengimplementasikan passkey di aplikasi native (iOS + Android). Anda akan mempelajari jenis WebView mana yang direkomendasikan untuk autentikasi passkey.

Our mission is to make the Internet a safer place, and the new login standard passkeys provides a superior solution to achieve that. That's why we want to help you understand passkeys and its characteristics better.

1. Pilihan Implementasi Passkey Aplikasi Native#

Autentikasi berdiri sebagai penjaga, melindungi data pengguna dan memastikan interaksi yang aman dalam aplikasi native. Kemunculan passkey telah merevolusi bidang ini, menawarkan mekanisme autentikasi yang kuat dan ramah pengguna. Ada dua cara utama untuk mengintegrasikan passkey ke dalam aplikasi native, baik melalui implementasi native atau melalui WebView. Mari kita lihat terlebih dahulu perbandingan kedua cara tersebut.

1.1 Implementasi Native: UX yang Hebat#

Implementasi native sering dianggap memberikan pengalaman pengguna terbaik dalam sebuah aplikasi. Hal ini ditandai dengan interaksi pengguna yang lancar, terintegrasi, dan kohesif, yang disesuaikan secara tepat dengan lingkungan sistem operasi, baik itu iOS maupun Android. Syarat untuk implementasi 100% native adalah menjadi 100% tanpa kata sandi dan benar-benar passkey-native. Pendekatan ini membebaskan Anda dari potensi gesekan transisi antara aplikasi native dan konten web (yang ditampilkan melalui WebView).

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

1.2 Implementasi WebView: Pengalaman Mirip Browser#

Saat mengembangkan aplikasi native, jalur untuk menjadi sepenuhnya native tidak selalu memungkinkan. Dalam skenario di mana Anda masih perlu mendukung autentikasi berbasis kata sandi yang menggunakan OAuth2, integrasi native penuh mungkin tidak dapat dilakukan, menjadikan implementasi WebView sebagai satu-satunya alternatif yang layak. WebView bertindak sebagai jembatan, menyematkan konten web langsung di dalam aplikasi Anda, memberikan UX seperti browser saat menavigasi halaman web. Hal ini sangat relevan jika Anda adalah penyedia OAuth2 sendiri, solusi autentikasi yang mendasarinya berbasis OAuth2, atau jika solusi login Anda menggunakan login sosial melalui pihak ketiga, seperti Google atau GitHub. Dalam kasus ini, penggunaan WebView menjadi tak terhindarkan karena perlunya berinteraksi dengan konten web dan mengelola berbagai alur autentikasi pengguna, terutama ketika asosiasi aplikasi native diperlukan.

Pada intinya, meskipun implementasi native menawarkan pengalaman pengguna yang tak tertandingi dan lancar, implementasi tersebut mungkin tidak selalu menjadi pilihan yang layak, terutama jika digabungkan dengan solusi autentikasi berbasis kata sandi atau OAuth2. Di sisi lain, implementasi WebView menyediakan jalur yang fleksibel, meskipun sedikit kurang mulus, untuk mengintegrasikan konten web dan mengelola autentikasi pengguna di dalam aplikasi Anda, memastikan Anda dapat menavigasi kompleksitas berbagai alur autentikasi dan login pihak ketiga.

Bagian selanjutnya dari artikel ini berfokus pada implementasi melalui WebView. Untuk mempelajari lebih lanjut tentang integrasi passkey native, silakan lihat di sini.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

10,000+ devs trust Corbado & make the Internet safer with passkeys. Got questions? We’ve written 150+ blog posts on passkeys.

Join Passkeys Community

2. Ikhtisar Opsi WebView#

Menavigasi labirin autentikasi di aplikasi native, pengembang dan manajer produk menghadapi keputusan penting: mengimplementasikan autentikasi passkey secara native atau melalui WebView. Jika memutuskan untuk yang terakhir, platform iOS dan Android menawarkan dua jenis WebView yang berbeda, masing-masing dengan atribut unik dan potensi kasus penggunaannya.

2.1 WebView iOS#

WKWebView
SFSafariViewController
SFAuthenticationSession / ASWebAuthenticationSession (khusus disesuaikan untuk alur autentikasi berbasis OAuth / OpenID Connect)

2.2 WebView Android#

WebView
Chrome Custom Tabs (CCT)

Di bagian berikut, kita akan membahas lebih dalam tentang jenis-jenis WebView ini dan pada akhirnya memandu Anda untuk membuat keputusan yang tepat tentang WebView mana yang akan digunakan untuk autentikasi passkey di aplikasi native Anda (jika implementasi native murni bukan merupakan alternatif).

Subscribe to our Passkeys Substack for the latest news.

3. WebView di iOS#

WebView iOS adalah WKWebView atau SFSafariViewController (jika bekerja dengan OAuth / OIDC, itu adalah SFAuthenticationSession / ASWebAuthenticationSession).

Untuk menguji perilaku WebView yang berbeda di iOS, kami merekomendasikan aplikasi WebView - WKWebView and UIWebView rendering.

3.1 WKWebView#

WKWebView adalah opsi WebView yang kuat dan serbaguna yang tersedia untuk pengembang iOS. Diperkenalkan dengan iOS 8, ini memungkinkan pengembang untuk menyematkan konten web langsung di dalam aplikasi, menyediakan beragam opsi kustomisasi dan konfigurasi. WKWebView terkenal dengan kinerjanya, menggunakan mesin rendering web yang sama dengan Safari, dan menawarkan serangkaian API yang kaya untuk berinteraksi dengan konten web, mengelola navigasi, interaksi pengguna, dan banyak lagi.

3.2 SFSafariViewController#

SFSafariViewController adalah WebView yang memungkinkan pengembang untuk memanfaatkan kemampuan Safari langsung di dalam aplikasi mereka. Ini memberikan pengalaman pengguna yang mulus dengan memanfaatkan pengaturan Safari pengguna, seperti kata sandi yang tersimpan, passkey, cookie, dan lainnya, memastikan penjelajahan web yang konsisten, karena sebenarnya berjalan sebagai aplikasi Safari. SFSafariViewController tidak dapat disesuaikan seperti WKWebView tetapi menawarkan fitur keamanan yang ditingkatkan dan kemudahan penggunaan, menjadikannya pilihan utama untuk menampilkan konten web yang lugas di dalam aplikasi.

	WKWebView	SFSafariViewController
Pengalaman pengguna	- Terasa native: Pengguna mungkin merasa bahwa konten web adalah bagian native dari aplikasi karena pengembang dapat menyesuaikan tampilan dan nuansa agar sesuai dengan desain aplikasi. - Isi otomatis: Isi otomatis dengan data dari Safari dimungkinkan	- Mulus: Pengalaman pengguna yang mulus menggunakan pengaturan Safari pengguna memastikan penjelajahan web yang konsisten antara aplikasi native dan browser.
Pengalaman pengembang	- Sangat dapat disesuaikan: Kustomisasi dan konfigurasi ekstensif tersedia - Fleksibel: Banyak API untuk berinteraksi dengan konten web	- Cukup dapat disesuaikan: Opsi kustomisasi terbatas, terutama dibandingkan dengan WKWebView, - Sederhana: Lebih mudah diimplementasikan dibandingkan dengan WKWebView
Kinerja	- Cenderung lambat: Tergantung pada implementasi dan konten web, kecepatan pemuatan dapat dioptimalkan, tetapi mungkin masih lebih lambat dibandingkan dengan SFSafariViewController karena pemrosesan tambahan fitur dan interaksi kustom.	- Cenderung cepat: Biasanya menawarkan kinerja yang lebih baik karena memanfaatkan mesin Safari, yang dioptimalkan untuk kecepatan dan efisiensi, memberikan waktu muat yang cepat untuk halaman web.
Kepercayaan dan pengenalan	- Tampilan URL tidak diperlukan: WKWebView sering kali tidak menampilkan URL, sehingga menyulitkan pengguna untuk memverifikasi halaman web. Potensi aplikasi berbahaya untuk meniru perilaku ini dan melakukan phishing kredensial.	- Pengalaman Mirip Browser: Merender halaman web menggunakan Safari, memberikan pengalaman "mirip browser". Pengguna dapat melihat URL dan mengakses fitur isi otomatis Safari, yang berpotensi menanamkan lebih banyak kepercayaan karena antarmuka yang familier.
Isolasi	- Terpisah: Cookie dan sesi dipisahkan dari Safari; pengguna tidak akan secara otomatis masuk ke WKWebView.	- Terpisah: Cookie dan sesi dipisahkan dari Safari; pengguna juga tidak akan secara otomatis masuk ke SFSafariViewController.
Kerentanan	- Aman: Secara inheren aman karena sandboxing aplikasi Apple, tetapi perilaku dan keamanan bergantung pada implementasi aplikasi. Potensi kerentanan jika tidak diimplementasikan dengan benar.	- Lebih Aman: Mendapat manfaat dari fitur keamanan bawaan Safari, termasuk peringatan anti-phishing dan situs web berbahaya. Umumnya dianggap lebih aman untuk menampilkan konten web daripada WKWebView karena fitur-fitur ini dan keakraban pengguna dengan Safari.
Lainnya	- Fitur tidak tersedia: Beberapa fitur browser (misalnya, WebAuthn) mungkin tidak sepenuhnya dapat diakses karena masalah keamanan dan WKWebView berjalan dalam konteks aplikasi. - Injeksi JavaScript: Beberapa aplikasi, mis. TikTok menyuntikkan JavaScript pelacakan ke dalam WKWebView dalam aplikasi mereka, atau membatasi kontrol pengguna (mis. Facebook) - Masalah privasi: Lebih banyak umpan balik komunitas mengenai privasi	- Tidak ada injeksi JavaScript: Tidak mengizinkan eksekusi JavaScript dari aplikasi, meningkatkan keamanan dan privasi. Juga tidak mendukung peringatan atau konfirmasi JavaScript, yang berpotensi memengaruhi pengalaman pengguna di halaman web tertentu. - Mode Pembaca: Menyediakan mode pembaca untuk versi artikel yang bersih dan mudah dibaca.

3.3 SFAuthenticationSession / ASWebAuthenticationSession#

SFAuthenticationSession dan ASWebAuthenticationSession adalah WebView yang secara khusus disesuaikan untuk alur autentikasi berbasis OAuth / OpenID Connect. Keduanya menyediakan ruang yang aman dan terisolasi untuk autentikasi pengguna, melindungi kredensial pengguna dan memastikan bahwa informasi pribadi tidak secara tidak sengaja dibagikan dengan aplikasi. Sesi ini berbagi cookie dan data situs web dengan Safari, memberikan pengalaman pengguna yang konsisten dan mulus, terutama selama proses autentikasi.

Kelebihan:

Autentikasi Khusus: Dirancang khusus untuk alur autentikasi berbasis OAuth / OpenID Connect, memastikan proses autentikasi yang efisien.
Perlindungan Privasi: Memastikan privasi data pengguna dengan tidak membagikan cookie atau data situs web dengan aplikasi.
Dukungan SSO: Mendukung Single Sign-On, memberikan pengalaman pengguna yang nyaman.

Kekurangan:

Kasus Penggunaan Terbatas : Terutama berfokus pada autentikasi OAuth / OpenID Connect, yang mungkin tidak cocok untuk semua kasus penggunaan.

Ketika tugas utamanya adalah autentikasi pengguna, terutama saat mengimplementasikan SSO atau berinteraksi dengan penyedia OAuth, Anda harus menggunakan SFAuthenticationSession / ASWebAuthenticationSession alih-alih SFSafariViewController.

Want to find out how many people use passkeys?

View Adoption Data

4. WebView di Android#

WebView Android adalah WebView atau Chrome Custom Tabs (CCT). Untuk menguji perilaku WebView yang berbeda di Android, kami merekomendasikan aplikasi WebView vs Chrome Custom Tabs.

4.1 Android WebView#

WebView di Android adalah komponen komprehensif yang memungkinkan pengembang menampilkan konten web sebagai bagian dari UI aplikasi. Ini serbaguna, menawarkan berbagai pilihan kustomisasi dan memberikan fleksibilitas kepada pengembang untuk mengonfigurasi WebView agar sesuai dengan berbagai kebutuhan. WebView menyediakan serangkaian API yang kaya untuk berinteraksi dengan konten web, mengelola interaksi pengguna, dan bahkan menangani dialog JavaScript, sertifikat klien, dan permintaan izin.

4.2 Chrome Custom Tabs (CCT)#

Chrome Custom Tabs (CCT) menawarkan cara yang mulus, aman, dan efisien untuk mengintegrasikan konten web langsung ke dalam aplikasi Anda. Dengan memanfaatkan kemampuan dan fitur keamanan Chrome, CCT memberikan pengalaman pengguna yang konsisten dan berkinerja tinggi.

CCT adalah komponen dari browser Chrome, yang dirancang untuk berintegrasi dengan kerangka kerja Android, memungkinkan aplikasi untuk membuka konten web dalam proses khusus yang ringan. Khususnya, ini terbuka lebih cepat daripada browser konvensional dan, ketika dimuat sebelumnya melalui panggilan pemanasannya, berpotensi mengungguli WebView. Meskipun menjalankan JavaScript, ia beroperasi dalam prosesnya sendiri, melindungi aplikasi dari menjalankan kode berbahaya. Selain itu, UI CCT menyediakan bilah tindakan, menampilkan URL dan ikon gembok verifikasi SSL untuk halaman yang aman, sehingga meyakinkan pengguna tentang keaslian dan keamanan halaman yang dimuat.

Secara umum, dapat dikatakan bahwa iOS WKWebView dan Android WebView, serta SFSafariViewController dan Chrome Custom Tabs (CCT) serupa.

Fitur	WebView	Chrome Custom Tab
Pengalaman pengguna	- Fleksibilitas: Menyediakan serangkaian API yang kaya untuk berinteraksi dengan konten web dan mengelola interaksi pengguna, termasuk menangani dialog JavaScript dan permintaan izin. - Konsistensi: Mengelola UX yang konsisten, terutama dengan konten web yang bervariasi, bisa menjadi tantangan.	- Fitur Browser: Berbagi fitur seperti Penghemat Data dan AutoComplete yang disinkronkan di seluruh perangkat. - Tombol Kembali: Memungkinkan pengguna untuk dengan mudah kembali ke aplikasi dengan tombol kembali yang terintegrasi. - Ketergantungan: Bergantung pada aplikasi Chrome, yang mungkin tidak tersedia atau diperbarui di semua perangkat pengguna - Pengalihan ke Browser: Fungsionalitas tertentu mungkin mengalihkan pengguna ke aplikasi Chrome, yang berpotensi mengganggu pengalaman pengguna. - Tab Kustom Parsial: Hanya sebagian layar yang dapat digunakan untuk Chrome Custom Tab sementara sisanya menampilkan aplikasi native - Side-sheet: Dalam mode lanskap dan pada perangkat layar besar, Chrome Custom Tab hanya ditampilkan di satu sisi layar, sementara sisa layar menampilkan aplikasi native
Pengalaman pengembang	- Sangat Dapat Disesuaikan: Menawarkan opsi/kebutuhan kustomisasi yang luas. - Interaktivitas: Menyediakan banyak API untuk berinteraksi dengan konten web dan mengelola interaksi pengguna.	- Dapat Disesuaikan: Memungkinkan kustomisasi warna toolbar, tombol tindakan, toolbar bawah, item menu kustom, dan animasi masuk/keluar. - Callback: Memberikan callback ke aplikasi setelah navigasi eksternal. - Fitur Keamanan: Menyediakan fitur siap pakai, menghilangkan kebutuhan untuk mengelola permintaan, pemberian izin, atau penyimpanan cookie.
Kinerja	- Kinerja Sedang: Mungkin tidak menawarkan tingkat kinerja yang sama dengan Chrome Custom Tabs (CCT)	- Pre-Warming: Termasuk pemanasan awal Browser di latar belakang dan pemuatan spekulatif URL untuk meningkatkan waktu muat halaman. - Prioritas: Mencegah aplikasi yang meluncurkan Custom Tab dari penggusuran selama penggunaannya dengan meningkatkan kepentingannya ke tingkat "latar depan".
Kepercayaan dan pengenalan	- URL & SSL tidak Terlihat: URL dan informasi SSL tidak secara inheren terlihat di WebView. Kecuali pengembang aplikasi mengimplementasikan fitur-fitur ini, pengguna tidak akan tahu apakah mereka berada di situs web yang benar atau situs phishing.	- URL & SSL Terlihat: Menggunakan browser Chrome yang sebenarnya untuk merender halaman. Pengguna dapat melihat URL dan sertifikat SSL (menunjukkan apakah koneksi aman). Ini dapat memberikan kepercayaan kepada pengguna bahwa mereka tidak berada di situs phishing.
Isolasi	- Berjalan dalam Proses Aplikasi: Jika sebuah aplikasi memiliki kerentanan yang memungkinkan eksekusi kode berbahaya, ada risiko bahwa WebView dapat disusupi. Namun, WebView juga menerima pembaruan, tetapi perilaku dan keamanannya bisa lebih bergantung pada aplikasi yang menggunakannya. - Tidak Ada Berbagi Cookie / Sesi: Tidak berbagi cookie atau sesi dengan browser utama perangkat, menawarkan isolasi tetapi mungkin mengharuskan pengguna untuk masuk lagi.	- Berjalan dalam Proses Chrome: Menjadi bagian dari Chrome, Custom Tabs berjalan dalam proses yang sama dan memiliki pembaruan keamanan dan fitur yang sama dengan Chrome. - Model Berbagi Cookie Jar dan Izin: Memastikan pengguna tidak perlu masuk kembali ke situs atau memberikan kembali izin. - Pengaturan & Preferensi Chrome: Memanfaatkan pengaturan dan preferensi Chrome.
Kerentanan	- Callback untuk Mencuri Kredensial: Potensi kerentanan termasuk bahwa terkadang JavaScript diperlukan yang membuka pintu bagi aplikasi lain untuk menjalankan kode berbahaya, seperti mendaftarkan callback yang mencoba mencegat nama pengguna dan kata sandi. - Phishing: Selain itu, aplikasi berbahaya dapat membuka halaman web lain yang meniru alur Tautan dalam upaya phishing.	- Google Safe Browsing: Menggunakan Google Safe Browsing untuk melindungi pengguna dan perangkat dari situs berbahaya. - Dekorasi Browser Aman: Memastikan pengguna selalu melihat URL yang tepat yang mereka gunakan dan dapat melihat informasi sertifikat situs web, mengurangi risiko phishing. Selain itu, tab kustom tidak mengizinkan injeksi JavaScript.
Lainnya	- Google melarang WebView untuk login pengguna ke akun Google

5. Rekomendasi Implementasi Passkey di Aplikasi Native#

Pelanggan kami terus-menerus bertanya kepada kami tentang bagaimana passkey harus diimplementasikan di aplikasi native. Sebagian besar pelanggan tersebut dapat dibagi menjadi beberapa kelompok:

Grup A:

Pelanggan yang mulai membangun aplikasi native mereka dari awal dan dapat langsung menggunakan autentikasi tanpa kata sandi kami (tidak ada kata sandi lama yang ada).

Grup B:

Pelanggan dengan pengguna yang sudah ada dan solusi autentikasi yang sudah ada. Seringkali mereka juga sudah memiliki aplikasi web yang juga perlu menambahkan passkey ke dalam proses autentikasinya. Di sini banyak perusahaan memutuskan untuk melakukan proses dua langkah:

Tambahkan passkey ke alur autentikasi WebView Anda yang sudah ada (begitulah cara Google dan GitHub mengimplementasikannya di aplikasi native mereka)
Tambahkan passkey melalui implementasi native di atasnya. Implementasi passkey native ini memeriksa sebelum WebView lama (misalnya untuk login sosial dan kata sandi) apakah pengguna dapat login dengan passkey (begitulah cara KAYAK mengimplementasikannya di aplikasi native mereka).

Tentukan Grup Anda

Untuk memberikan pengguna Anda implementasi passkey terbaik di aplikasi native, Anda perlu memutuskan kelompok mana Anda berada, berdasarkan pengaturan teknis Anda saat ini dan bagaimana Anda ingin mendorong passkey (pertanyaan ini relevan untuk perusahaan di grup B).

Rekomendasi untuk Grup A: Implementasi Native

Jika Anda membangun aplikasi yang sepenuhnya baru (grup A), kami merekomendasikan untuk menggunakan implementasi passkey native dan langsung sepenuhnya tanpa kata sandi (jadi tidak ada jenis WebView yang digunakan). Silakan gunakan SDK & API native untuk iOS dan Android (misalnya melalui paket Flutter passkeys). Silakan baca juga artikel ini tentang Relying Party ID.

Rekomendasi untuk Grup B: Pertama WebView, lalu Implementasi Native

Jika Anda tidak dapat mengimplementasikan passkey secara native hari ini karena alasan apa pun (grup B), Anda dapat memulai dengan implementasi WebView dan kemudian di masa depan beralih ke implementasi passkey native (ini berfungsi melalui pembuatan file asosiasi, seperti apple-app-site-association untuk aplikasi iOS dan assetlinks.json untuk aplikasi Android). Alasan untuk menggunakan implementasi WebView mungkin termasuk:

Anda sudah menawarkan autentikasi berbasis OAuth2 dan ingin tetap menawarkannya kepada pengguna Anda (OAuth2 tidak berfungsi secara native, lihat standar di sini)
Anda ingin menawarkan autentikasi passkey di jendela / layar yang sama, di mana Anda menawarkan metode autentikasi lainnya (misalnya kata sandi, login sosial, OAuth2)

Ini adalah cara yang telah diterapkan oleh Google atau GitHub untuk autentikasi passkey di aplikasi native mereka saat ini. Silakan lihat rekomendasi di bawah ini untuk menyiapkan WebView dengan benar untuk autentikasi passkey. Namun, kami merekomendasikan untuk mempertimbangkan implementasi passkey native seperti yang dilakukan KAYAK dan langsung memulai dengan langkah 2.

Jika Anda termasuk dalam grup B dan tidak dapat mengimplementasikan passkey secara native, rekomendasi kami cenderung ke arah penggunaan SFAuthenticationSession / ASWebAuthenticationSession untuk iOS dan Chrome Custom Tabs untuk Android (jika tidak, passkey tidak akan berfungsi).

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

Try for Free

Berikut ini, kami menyatakan alasan untuk rekomendasi ini:

SFAuthenticationSession / ASWebAuthenticationSession berbagi cookie dan data situs web dengan Safari, memberikan pengalaman pengguna yang mulus selama proses autentikasi. Hal yang sama berlaku untuk Chrome Custom Tabs di Android.

Pengguna mendapat manfaat dari kata sandi yang tersimpan, data isi otomatis, dan informasi lain yang tersimpan di browser, membuat proses autentikasi lebih lancar dan lebih cepat.

5.2 Keamanan yang Ditingkatkan#

SFAuthenticationSession / ASWebAuthenticationSession di iOS dan Chrome Custom Tabs di Android menyediakan ruang yang aman dan terisolasi untuk autentikasi pengguna, memastikan bahwa kredensial pengguna yang sensitif terlindungi dan tidak secara tidak sengaja dibagikan dengan aplikasi atau situs web lain.

Mereka mematuhi protokol keamanan ketat Apple dan Google, memastikan bahwa data pengguna ditangani dengan aman dan privasi terjaga.

Selain itu, pilihan desain ini mendapat manfaat dari pembaruan dan peningkatan keamanan berkelanjutan Safari dan Chrome, memastikan bahwa ia mematuhi standar dan protokol keamanan terbaru.

5.3 Pengalaman Pengguna#

SFAuthenticationSession / ASWebAuthenticationSession di iOS dan Chrome Custom Tabs di Android memberikan antarmuka pengguna yang konsisten dan familier, karena pengguna terbiasa dengan pengalaman pengguna browser. Selain itu, pengaturan dan preferensi pengguna Safari dan Chrome diterapkan.

Ini memberikan transisi yang mulus antara konten aplikasi dan konten web, memastikan bahwa pengguna tidak terganggu oleh perpindahan antarmuka.

5.4 Kinerja#

Chrome Custom Tabs memanfaatkan kinerja Chrome, memastikan pengalaman pengguna yang lancar dan responsif, yang sangat penting selama proses autentikasi untuk mencegah frustrasi atau pengabaian pengguna.

Kinerja CCT seringkali lebih unggul dari opsi Android WebView (sama dengan SFAuthenticationSession / ASWebAuthenticationSession di iOS), memastikan bahwa konten web dan alur autentikasi ditangani dengan cepat dan lancar.

Lihat juga perbandingan oleh Google ini untuk merasakan perbedaan kinerja antara Chrome Custom Tabs, Android WebView dan browser Chrome standar.

5.5 Didedikasikan untuk Alur Autentikasi#

SFAuthenticationSession / ASWebAuthenticationSession dirancang khusus untuk menangani alur autentikasi berbasis OAuth / OpenID Connect, memastikan proses yang efisien dan aman untuk protokol autentikasi yang banyak digunakan ini. Ini juga merupakan cara yang direkomendasikan untuk autentikasi WebAuthn / passkey.

Di Android, tidak ada kelas khusus untuk alur autentikasi tetapi perilaku serupa dapat diimplementasikan dengan Chrome Custom Tabs dan Android App Links.

Selanjutnya, kami berharap lebih banyak aplikasi akan memperkenalkan passkey seperti TikTok hanya dengan mengumpulkannya saat pengguna diautentikasi. Ini dapat dilakukan secara native (implementasi TikTok) atau melalui implementasi WebView. Pendekatan yang sesuai adalah dengan memicu Conditional UI secara native. Jika tidak berhasil, Anda menampilkan implementasi WebView.

6. Kesimpulan#

Dalam lanskap autentikasi digital modern, implementasi passkey melalui WebView di aplikasi native muncul sebagai mercusuar praktik yang aman dan ramah pengguna. Meskipun perjalanan dalam memilih WebView yang optimal mungkin rumit, sangat penting untuk menyelaraskan pilihan teknologi dengan pengalaman pengguna dan keamanan.