Passkey Aplikasi Native: Implementasi Native vs. WebView

60-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

Catatan: System dan Embedded WebView sering digabungkan di mana System WebView menangani login (dengan pembagian kredensial otomatis), kemudian Embedded WebView merender manajemen passkey di pengaturan.

Faktor Keputusan Utama:

• Login berbasis OAuth? → System WebView (ASWebAuthenticationSession, Chrome Custom Tabs)
• Ingin menggunakan kembali autentikasi web dalam shell native? → Embedded WebView (WKWebView, WebView Android dengan WebKit 1.12.1+)
• Membangun aplikasi yang mengutamakan native? → Implementasi Native (Apple AuthenticationServices, Google Credential Manager)

Platform seluler modern menyediakan tiga pendekatan berbeda untuk mengintegrasikan passkey ke dalam aplikasi native Anda, masing-masing dengan pertimbangan berbeda untuk pengalaman pengguna, kompleksitas teknis, dan kompatibilitas OAuth:

1. Implementasi Native: Membangun alur passkey langsung ke dalam aplikasi Anda menggunakan API platform (iOS AuthenticationServices, Android Credential Manager). Memberikan pengalaman pengguna terbaik dengan autentikasi biometrik yang mulus, tetapi memerlukan upaya implementasi teknis sedang hingga tinggi.

2. System WebView: Menggunakan komponen browser platform (iOS ASWebAuthenticationSession / SFSafariViewController, Android Chrome Custom Tabs) untuk menangani autentikasi. Sangat baik untuk alur login berbasis OAuth dan berbagi kredensial dengan browser sistem.

3. Embedded WebView: Menyematkan web view yang dapat disesuaikan (iOS WKWebView, Android WebView) di dalam aplikasi Anda untuk menggunakan kembali autentikasi web dengan kerangka aplikasi native. Memberikan tampilan seperti native tanpa bilah URL dan kontrol penuh atas UI web view. Memerlukan penyiapan tambahan termasuk izin dan entitlement (iOS), dan konfigurasi WebView dengan AndroidX WebKit 1.12.1+ (Android) untuk mengaktifkan fungsionalitas passkey.

Pilihan yang tepat tergantung pada arsitektur autentikasi aplikasi Anda, apakah Anda menggunakan penyedia OAuth, seberapa besar kontrol yang Anda butuhkan atas UI, dan apakah Anda membangun aplikasi yang mengutamakan native atau menggunakan kembali komponen web.

Implementasi passkey native memberikan pengalaman pengguna yang optimal, dengan alur autentikasi yang dibangun langsung ke dalam UI aplikasi Anda menggunakan API spesifik platform. Pengguna mendapat manfaat dari dialog native platform, verifikasi biometrik yang mulus, dan waktu login tercepat.

Kapan memilih Implementasi Native:

• Membangun aplikasi native baru atau merefaktor autentikasi ke layar native
• Menginginkan pengalaman pengguna terbaik dengan autentikasi instan dan senyap
• Prompt passkey otomatis saat aplikasi dimulai: Implementasi native dapat menggunakan preferImmediatelyAvailableCredentials untuk secara otomatis menampilkan overlay passkey saat passkey tersedia, memberikan pengalaman login tercepat tanpa perlu memasukkan pengenal
• Membutuhkan kontrol penuh atas UI dan alur autentikasi
• Bersedia berinvestasi dalam implementasi spesifik platform (iOS Swift, Android Kotlin)

Keuntungan Utama: preferImmediatelyAvailableCredentials()

Implementasi native dapat memanfaatkan preferImmediatelyAvailableCredentials() untuk membuat overlay passkey otomatis yang muncul segera saat aplikasi dimulai ketika passkey tersedia. Alur tanpa nama pengguna ini memberikan pengalaman login tercepat—pengguna melihat passkey mereka secara instan tanpa memasukkan pengenal terlebih dahulu. Kemampuan ini eksklusif untuk implementasi native dan tidak tersedia dalam varian WebView.

Sementara implementasi WebView dapat menggunakan Conditional UI (saran passkey di kolom input), overlay otomatis dari implementasi native memberikan UX yang superior dengan tingkat penggunaan passkey yang lebih tinggi karena autentikasi dimulai segera setelah aplikasi diluncurkan.

Gambaran Persyaratan Teknis:

Integrasi passkey native memerlukan kepercayaan kriptografis antara aplikasi Anda dan domain web. Tanpa itu, OS akan menolak semua operasi WebAuthn. Persyaratan utama:

1. File Asosiasi App-Domain yang dihosting di /.well-known/
2. Relying Party ID yang Benar yang cocok dengan domain web Anda
3. Kapabilitas Spesifik Platform (dirinci di Bagian 4)

Manfaat utamanya: passkey yang dibuat di situs web Anda berfungsi mulus di aplikasi Anda dan sebaliknya.

Mengimplementasikan passkey secara native di iOS melibatkan kerangka AuthenticationServices Apple, yang menyediakan API untuk operasi WebAuthn:

Komponen Utama:

• ASAuthorizationController: Mengelola alur autentikasi
• ASAuthorizationPlatformPublicKeyCredentialProvider: Membuat permintaan passkey
• Tiga mode UI yang berbeda untuk menangani login passkey:
• Login via kolom teks: Kolom nama pengguna tradisional dengan login passkey yang dimulai saat tombol diklik
• Overlay modal passkey: Dialog OS yang menampilkan passkey yang tersedia
• Conditional UI: Saran passkey di bilah QuickType di atas keyboard

Tips Pengembangan

• Caching AASA: Apple melakukan cache file AASA secara agresif (hingga 24 jam), yang dapat menyulitkan pengujian. Solusi: Aktifkan Mode Pengembang di perangkat pengujian Anda dan tambahkan ?mode=developer ke URL AASA Anda untuk memaksa pengambilan ulang data baru
• Pengujian Kinerja: Uji dengan akun iCloud yang berisi ratusan kredensial untuk mengamati latensi dunia nyata. Overlay sistem mungkin menunjukkan sedikit keterlambatan dengan banyak passkey yang tersimpan

Implementasi passkey native Android menggunakan Credential Manager API (atau API FIDO2 yang lebih lama untuk kompatibilitas mundur):

Komponen Utama:

• CredentialManager: API pusat untuk semua operasi kredensial
• CreatePublicKeyCredentialRequest: Untuk registrasi passkey
• GetCredentialRequest: Untuk autentikasi passkey
• Dua mode UI utama:
• Login via kolom teks: Kolom nama pengguna tradisional dengan login passkey yang dimulai saat tombol diklik
• Overlay modal passkey: Dialog OS yang menampilkan passkey yang tersedia

Catatan: Android saat ini tidak memiliki saran keyboard Conditional UI seperti iOS di aplikasi native (meskipun Conditional UI berfungsi di aplikasi web)

Mengimplementasikan passkey secara native memiliki tantangan dan pelajaran penting: Mengintegrasikan di tingkat OS dapat memunculkan masalah di berbagai perangkat dan versi OS.

1. Misalnya, tim kami menemukan masalah seperti caching agresif Apple terhadap file apple-app-site-association (digunakan untuk menautkan kredensial aplikasi/web) dan perbedaan UI yang halus dalam prompt biometrik OEM Android tertentu.
2. Selain itu, pertimbangkan bahwa dalam beberapa skenario perusahaan, perangkat yang dikelola mungkin memiliki sinkronisasi passkey yang dinonaktifkan oleh kebijakan. Di lingkungan korporat di mana sinkronisasi iCloud Keychain atau Google Password Manager dimatikan, passkey menjadi terikat pada perangkat dan tidak akan berpindah—skenario penting untuk direncanakan (misalnya, memastikan pengguna masih bisa login jika mereka mendapatkan ponsel baru).
3. Selain itu, aplikasi pengelola kredensial pihak ketiga dapat memengaruhi alur. Misalnya, jika pengguna memiliki pengelola kata sandi seperti 1Password yang ditetapkan sebagai penyedia kredensial aktif, itu akan sering mencegat pembuatan dan penyimpanan passkey, mengambil prioritas di atas pengelola kredensial native platform.

Meski Anda dapat mengimplementasikan passkey menggunakan API platform mentah, SDK yang dibuat khusus secara signifikan mempercepat pengembangan dengan menangani kompleksitas WebAuthn, kasus-kasus khusus, dan menyediakan telemetri bawaan. SDK juga menawarkan antarmuka yang dapat di-mock untuk pengujian unit (penting karena Anda tidak dapat menguji biometrik di simulator).

Rekomendasi: Untuk implementasi native, kami merekomendasikan penggunaan SDK Corbado (SDK Passkey iOS Swift, SDK Passkey Android Kotlin) yang menangani banyak kasus khusus yang ditemukan melalui penerapan produksi, menyediakan telemetri dan pengujian tambahan.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Passkey yang diadopsi jutaan orang, dengan cepat. Mulai dengan Platform Adopsi Corbado.

Mulai Uji Coba Gratis

System WebView menggunakan komponen browser native platform untuk menangani autentikasi di dalam aplikasi Anda. Berbeda dari implementasi yang sepenuhnya native, System WebView menampilkan konten web menggunakan browser sistem yang sebenarnya (Safari di iOS, Chrome di Android), mempertahankan cookie bersama, kredensial tersimpan, dan indikator keamanan browser yang sudah dikenal.

Kapan memilih System WebView:

• Aplikasi Anda menggunakan login berbasis OAuth: System WebView adalah pendekatan yang direkomendasikan untuk alur OAuth2/OIDC, menyediakan autentikasi yang aman
• Autentikasi berbasis web yang sudah ada yang ingin Anda gunakan kembali di aplikasi seluler
• Perlu mendukung beberapa metode autentikasi (kata sandi, social login, passkey) tanpa membangun ulang secara native
• Ingin mempertahankan satu basis kode autentikasi di seluruh web dan seluler

Keuntungan Utama:

• Kompatibilitas OAuth: Dibuat khusus untuk alur autentikasi OAuth/OIDC
• Indikator keamanan: Pengguna melihat URL dan sertifikat SSL yang sebenarnya, membangun kepercayaan
• Upaya implementasi rendah: Kode native yang diperlukan minimal
• UX yang konsisten: Antarmuka browser yang familier dan sudah dipercaya pengguna

Komponen Platform:

• iOS: ASWebAuthenticationSession (direkomendasikan untuk alur autentikasi) atau SFSafariViewController (penjelajahan umum)
• Android: Chrome Custom Tabs (CCT)

Perusahaan besar seperti Google dan GitHub mengadopsi pendekatan ini untuk menambahkan login passkey ke aplikasi seluler mereka melalui overlay WebView pada halaman autentikasi web yang ada. Ini berfungsi dengan baik ketika pembuatan ulang autentikasi yang sepenuhnya native tidak dapat segera dilakukan.

iOS menyediakan dua komponen System WebView utama untuk autentikasi:

ASWebAuthenticationSession (Direkomendasikan untuk Autentikasi):

• Dibuat khusus untuk alur OAuth/OIDC dan login yang aman
• Secara otomatis meminta izin kepada pengguna bahwa aplikasi ingin melakukan autentikasi
• Berbagi cookie dan kredensial dengan Safari
• Mendukung passkey melalui iCloud Keychain

SFSafariViewController (Penjelajahan Umum):

• Pengalaman Safari penuh di dalam aplikasi
• Menampilkan bilah URL dan indikator keamanan
• Tidak berbagi cookie Safari di iOS 11+; gunakan ASWebAuthenticationSession saat berbagi sesi Safari diperlukan
• Kurang dapat disesuaikan tetapi lebih dapat dipercaya oleh pengguna

Jika aplikasi Anda menggunakan login berbasis OAuth, ASWebAuthenticationSession adalah pilihan yang direkomendasikan karena dirancang khusus untuk skenario autentikasi dan memberikan keseimbangan terbaik antara keamanan dan pengalaman pengguna.

Chrome Custom Tabs (CCT) menyediakan pengalaman autentikasi yang didukung Chrome di dalam aplikasi Anda:

Fitur Utama:

• Berbagi cookie dan kredensial dengan browser Chrome
• Menampilkan URL dan indikator keamanan
• Dapat menyesuaikan warna bilah alat dan branding
• Pre-warming untuk waktu muat yang lebih cepat

Integrasi OAuth: Chrome Custom Tabs adalah padanan Android dari iOS ASWebAuthenticationSession, memberikan dukungan OAuth yang sangat baik sambil mempertahankan akses ke passkey yang tersimpan.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

Embedded WebView memberikan kontrol penuh atas rendering konten web di dalam aplikasi Anda, memungkinkan manipulasi langsung cookie, sesi, dan navigasi tanpa bilah URL. Namun, kontrol ini disertai dengan persyaratan teknis tambahan untuk mengaktifkan fungsionalitas passkey.

Kapan memilih Embedded WebView:

• Pengalaman seperti native: Aplikasi Anda sudah menyematkan autentikasi di dalam web view yang disesuaikan untuk mempertahankan tampilan dan nuansa native, dan Anda ingin menjaga pengalaman pengguna yang konsisten ini
• Membutuhkan kontrol sesi/cookie: Aplikasi Anda memerlukan manipulasi langsung token autentikasi dan status sesi setelah autentikasi OAuth selesai
• Alur autentikasi yang ada di mana autentikasi System WebView mengembalikan kode autentikasi tetapi tidak ada sesi dalam konteks yang disematkan
• Harus mempertahankan status terautentikasi di beberapa layar web yang disematkan
• Hanya autentikasi pihak pertama: Aplikasi Anda menangani autentikasi secara langsung, untuk implementasi passkey pihak ketiga lihat di sini
• AndroidX WebKit 1.12.1+ dengan deteksi fitur saat runtime
• Menerima batasan Conditional UI untuk Login (tidak didukung di Embedded WebView), tidak relevan untuk pengaturan manajemen

Konteks Penting:

Banyak aplikasi menggunakan pendekatan hibrida: System WebView menangani autentikasi OAuth awal (di mana passkey berfungsi mulus), lalu beralih ke Embedded WebView untuk pasca-autentikasi guna mengelola passkey di pengaturan. Tantangan muncul saat mencoba menggunakan passkey langsung di dalam Embedded WebView.

Persyaratan Teknis:

Embedded WebView memerlukan penyiapan tambahan dibandingkan dengan System WebView:

1. iOS: Entitlement Associated Domains, konfigurasi file AASA
2. Android: AndroidX WebKit 1.12.1+ dengan konfigurasi WebView WebAuthn (diperlukan deteksi fitur)
3. Keduanya: File asosiasi well-known dikonfigurasi dengan benar dan Digital Asset Links

Komponen Platform:

• iOS: WKWebView
• Android: android.webkit.WebView

Pertimbangan:

• Kompleksitas sedang: Memerlukan konfigurasi WebView (Android WebKit 1.12.1+) dan penyiapan entitlement (iOS)
• Adopsi passkey lebih rendah: Pengguna mungkin menghadapi lebih banyak gesekan dibandingkan dengan native
• Conditional UI tidak didukung: Pengisian otomatis passkey di kolom input tidak berfungsi di Android Embedded WebView
• Dukungan platform terbatas: Beberapa fitur mungkin tidak berfungsi secara konsisten (misalnya, pembuatan passkey otomatis)

Saat mengimplementasikan passkey melalui WebView, memahami perbedaan antara System WebView dan Embedded WebView sangat penting. Tiga pendekatan yang diuraikan di atas (Implementasi Native, System WebView, dan Embedded WebView) masing-masing melayani kasus penggunaan yang berbeda.

Di iOS, Anda memiliki beberapa opsi untuk menampilkan konten web di dalam aplikasi:

• WKWebView adalah WebView yang dapat disesuaikan yang merupakan bagian dari kerangka WebKit (diperkenalkan di iOS 8). Ini memberi Anda banyak kontrol atas penampilan dan perilaku konten web.
• SFSafariViewController adalah view controller yang disediakan oleh Apple yang bertindak sebagai browser Safari ringan di dalam aplikasi Anda. Ia menggunakan mesin Safari. Di iOS 11+, ia memiliki penyimpanan cookie terpisah dan tidak berbagi cookie Safari. Gunakan ASWebAuthenticationSession saat berbagi sesi Safari diperlukan.
• SFAuthenticationSession / ASWebAuthenticationSession adalah sesi autentikasi web khusus (tersedia sejak iOS 11/12) yang ditujukan khusus untuk alur OAuth/OpenID atau alur login aman lainnya. Ini juga memanfaatkan Safari di belakang layar, tetapi difokuskan pada alur autentikasi dan secara otomatis menangani hal-hal seperti cookie bersama dan Single Sign-On (SSO).

Di Android, pilihan utamanya adalah:

• Android WebView adalah widget WebView standar (android.webkit.WebView), yang pada dasarnya adalah browser mini yang dapat disematkan di aktivitas Anda. Ini sangat dapat disesuaikan tetapi berjalan dalam proses aplikasi Anda.
• Chrome Custom Tabs (CCT) adalah fitur yang membuka tab yang didukung Chrome di dalam konteks aplikasi Anda. Custom Tabs muncul sebagai bagian dari aplikasi Anda tetapi didukung oleh browser Chrome (jika terpasang) dengan fitur seperti pre-loading, cookie bersama, dan bilah URL yang familier untuk kepercayaan pengguna.

Di bagian berikut, kita akan membahas lebih dalam tentang jenis-jenis WebView ini untuk iOS dan Android, dan mendiskusikan mana yang mungkin paling cocok untuk alur autentikasi passkey.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Platform Apple menyediakan tiga opsi WebView yang tercantum di atas. Pilihan Anda akan memengaruhi seberapa lancar passkey dapat digunakan di dalam aplikasi:

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

WKWebView adalah komponen WebView serbaguna untuk iOS. Pengembang dapat menyematkan WKWebView untuk merender konten web dengan tingkat kontrol yang tinggi atas UI dan perilaku. WKWebView menggunakan mesin rendering yang sama dengan Safari, jadi sangat berkinerja dan mendukung fitur web modern. Secara teori, WKWebView dapat menangani WebAuthn (dan dengan demikian passkey) jika dikonfigurasi dengan benar, tetapi perlu dicatat bahwa beberapa fitur browser canggih mungkin dibatasi untuk keamanan. Satu hal yang perlu diperhatikan adalah bahwa WKWebView secara default tidak berbagi cookie atau data keychain dengan Mobile Safari. Pengguna mungkin harus login kembali karena sesi WebView mereka terisolasi dari sesi Safari. Juga, karena konten WKWebView dapat sepenuhnya disesuaikan oleh aplikasi, pengguna tidak melihat bilah alamat atau UI Safari – yang bagus untuk branding, tetapi itu berarti pengguna memiliki lebih sedikit petunjuk untuk memverifikasi keabsahan halaman (kekhawatiran untuk anti-phishing). Beberapa aplikasi bahkan telah menyalahgunakan WKWebView untuk menyuntikkan skrip atau mengubah konten (misalnya, TikTok tercatat menyuntikkan JS pelacakan melalui browser dalam aplikasinya), jadi orang harus berhati-hati menggunakan WKWebView dengan cara yang aman dan dapat dipercaya oleh pengguna.

SFSafariViewController menyediakan pengalaman Safari di dalam aplikasi. Saat Anda membuka URL dengan SFSafariViewController, hampir seperti membukanya di browser Safari asli, kecuali pengguna tetap berada di dalam UI aplikasi Anda. Keuntungannya untuk passkey sangat signifikan: karena ini pada dasarnya adalah Safari, iCloud Keychain dan passkey tersimpan milik pengguna dapat diakses. Perhatikan bahwa cookie tidak dibagikan di iOS 11+. Ini berarti jika pengguna sudah memiliki passkey untuk situs Anda, Safari dapat menemukannya dan bahkan menampilkan Conditional UI untuk login yang mudah. SFSafariViewController kurang dapat disesuaikan (Anda tidak dapat banyak mengubah bilah alatnya), tetapi ia secara otomatis menangani banyak fitur keamanan dan privasi. Bilah URL ditampilkan, lengkap dengan ikon gembok untuk HTTPS, yang memberi pengguna keyakinan bahwa mereka berada di domain yang benar. Secara umum, SFSafariViewController dianggap lebih aman daripada WKWebView mentah dan lebih sederhana untuk diimplementasikan (Apple menyediakannya sebagai komponen siap pakai). Pertimbangan utamanya adalah Anda mengorbankan sebagian kontrol atas tampilan & nuansa. Untuk alur autentikasi, itu biasanya dapat diterima. Prioritas di sini adalah keamanan dan kemudahan login, di mana SFSafariViewController unggul dengan menggunakan konteks Safari.

SFAuthenticationSession / ASWebAuthenticationSession – Kelas-kelas ini (yang terakhir adalah nama baru yang ramah Swift) dibuat khusus untuk alur login seperti OAuth atau OpenID Connect. Ketika Anda perlu mengautentikasi pengguna melalui halaman web (mungkin ke IdP eksternal), sesi ini adalah pilihan yang direkomendasikan di iOS. Mereka sangat mirip dengan SFSafariViewController karena mereka menggunakan browser Safari di belakang layar dan berbagi cookie/penyimpanan dengan Safari. Perbedaan utamanya adalah SFAuthenticationSession akan selalu meminta izin pengguna bahwa aplikasi ingin mengautentikasi menggunakan halaman web (untuk kesadaran pengguna) dan itu akan secara otomatis menggunakan sesi Safari yang ada jika tersedia.

Manfaatnya adalah pengalaman SSO yang mulus – jika pengguna sudah login ke penyedia di Safari, sesi ini dapat menggunakan cookie itu untuk menghindari login lain. Untuk passkey, ini penting karena berarti setiap kredensial passkey yang disimpan di Safari/iCloud Keychain dapat digunakan di sini juga. Panduan resmi Apple adalah menggunakan ASWebAuthenticationSession untuk apa pun yang terlihat seperti alur login. Keuntungannya adalah privasi yang ditingkatkan (aplikasi Anda tidak pernah melihat kredensial atau cookie, Safari yang menanganinya) dan dukungan SSO bawaan. Kelemahannya adalah itu terbatas pada alur autentikasi (Anda tidak akan menggunakannya hanya untuk merender konten web sewenang-wenang di aplikasi Anda). Singkatnya, jika Anda memilih pendekatan WebView di iOS, ASWebAuthenticationSession biasanya merupakan pilihan terbaik untuk mengimplementasikan passkey karena aman, berbagi status dengan Safari, dan dibuat khusus untuk autentikasi.

Want to find out how many people use passkeys?

View Adoption Data

Di Android, keputusan WebView adalah antara WebView klasik dan Chrome Custom Tabs:

Untuk menguji perilaku WebView yang berbeda di Android, kami merekomendasikan aplikasi WebView vs Chrome Custom Tabs.

Android WebView (android.webkit.WebView) adalah komponen yang memungkinkan Anda menyematkan halaman web di tata letak aktivitas Anda. Ini mirip dengan WKWebView karena memberi Anda kontrol penuh: Anda dapat mencegat navigasi, menyuntikkan JavaScript, menyesuaikan UI, dll. Ia juga berjalan di dalam proses aplikasi Anda. Menggunakan WebView untuk passkey berarti aplikasi Anda memuat halaman login web Anda, dan halaman itu dapat memulai seremoni passkey WebAuthn. Android WebView modern mendukung WebAuthn (asalkan implementasi WebView perangkat diperbarui melalui Android System WebView atau komponen Chrome). Satu pertimbangan utama: secara default, Android WebView tidak berbagi cookie atau kredensial yang tersimpan dengan browser Chrome pengguna. Jadi setiap passkey yang dibuat atau digunakan di WebView mungkin tidak diketahui oleh Chrome, dan sebaliknya. Isolasi ini bisa baik untuk keamanan (aplikasi Anda tidak bisa membaca cookie browser), tetapi mungkin memaksa pengguna untuk login lagi jika mereka sudah diautentikasi di Chrome. Masalah lainnya adalah kepercayaan. WebView biasa tidak menampilkan URL atau ikon kunci SSL, jadi pengguna harus mempercayai aplikasi Anda sepenuhnya untuk tidak melakukan phising. Google bahkan telah melarang penggunaan WebView untuk login Google OAuth karena potensi risiko phising. Dari segi kinerja, WebView baik-baik saja, tetapi bisa lebih lambat atau lebih intensif memori daripada menggunakan browser default pengguna, terutama jika memuat halaman yang berat.

Chrome Custom Tabs (CCT) adalah pendekatan hibrida. Mereka memungkinkan aplikasi Anda untuk membuka halaman yang dirender Chrome yang terlihat seperti bagian dari aplikasi Anda. Anda dapat menyesuaikan warna bilah alat, menambahkan logo aplikasi, dll., tetapi kontennya dirender oleh Chrome dalam proses terpisah. Untuk passkey, CCT memiliki beberapa manfaat: mereka berbagi cookie dan kredensial pengguna dengan Chrome, yang berarti jika pengguna memiliki passkey yang disimpan melalui Chrome (Google Password Manager), Custom Tab dapat mengaksesnya. Pengguna juga akan melihat URL dan indikator keamanan yang sebenarnya, yang membangun kepercayaan. Kinerja seringkali lebih baik – Chrome dapat "dipanaskan" di latar belakang untuk pemuatan yang lebih cepat. Dan yang penting, keamanannya kuat: karena pada dasarnya ini adalah aplikasi Chrome, hal-hal seperti Google Safe Browsing melindungi sesi, dan aplikasi Anda tidak dapat menyuntikkan skrip sewenang-wenang ke halaman (mencegah serangan tertentu).

Kelemahannya adalah mengharuskan pengguna untuk memiliki Chrome (atau browser yang didukung) yang terpasang dan diperbarui. Sebagian besar pengguna Android memilikinya, tetapi pada beberapa perangkat di wilayah tertentu, ini bisa menjadi masalah. Secara keseluruhan, jika Anda menggunakan pendekatan web tertanam di Android, Chrome Custom Tabs direkomendasikan untuk alur passkey, karena mereka memberikan keseimbangan yang baik antara integrasi dan keamanan. Faktanya, mereka analog dengan SFSafariViewController/ASWebAuthSession iOS dalam banyak hal – memanfaatkan browser default untuk autentikasi.

(Catatan samping: WKWebView vs SFSafariViewController Apple dan WebView vs CCT Android memiliki banyak kesamaan. Baik Safari VC maupun Chrome Tabs berbagi status browser dan memberikan keamanan yang lebih baik, sedangkan WKWebView/Android WebView memberikan lebih banyak kontrol tetapi mengisolasi konten web. Untuk passkey, berbagi status (cookie, penyimpanan kredensial) biasanya diharapkan agar passkey dapat diakses dan dibuat dengan mulus.)

Terlepas dari pendekatan implementasi mana yang Anda pilih, persyaratan teknis tertentu harus dipenuhi untuk mengaktifkan fungsionalitas passkey. Bagian ini memberikan panduan komprehensif tentang mengonfigurasi file asosiasi well-known, entitlement iOS, dan konfigurasi WebView Android.

Catatan tentang Perangkat Terkelola: Perilaku passkey berubah secara signifikan pada perangkat terkelola di mana kebijakan Mobile Device Management (MDM) mengontrol penyimpanan kredensial. Untuk menguji passkey pada perangkat terkelola, lihat Passkey di Perangkat iOS & Android Terkelola.

Alur Native dan Embedded WebView memerlukan file asosiasi untuk membangun kepercayaan kriptografis antara aplikasi dan domain web Anda. System WebView (ASWebAuthenticationSession) dan Chrome Custom Tabs tidak memerlukan asosiasi aplikasi-ke-situs.

File AASA membangun koneksi antara aplikasi iOS Anda dan domain web Anda, memungkinkan passkey berfungsi di kedua platform.

Lokasi File: https://yourdomain.com/.well-known/apple-app-site-association

Persyaratan Konfigurasi:

• Host di /.well-known/apple-app-site-association di domain Anda
• Disajikan melalui HTTPS dengan sertifikat SSL yang valid
• Content-Type: application/json
• Tidak ada pengalihan pada path .well-known
• Sertakan Team ID dan Bundle ID Aplikasi Anda

Contoh File AASA:

{
    "webcredentials": {
        "apps": ["TEAMID123.com.example.app"]
    }
}

Caching dan Pengujian AASA:

Apple secara agresif melakukan cache file AASA (hingga 24-48 jam) menggunakan CDN, yang dapat menyulitkan pengembangan dan pengujian. Untuk melewati caching selama pengembangan:

1. Aktifkan Mode Pengembang di perangkat pengujian Anda
2. Tambahkan ?mode=developer ke domain terkait Anda di Xcode
3. Ini memaksa iOS untuk mengambil file AASA terbaru langsung dari server Anda

⚠️ Penting: JANGAN gunakan ?mode=developer dalam rilis produksi. Parameter ini hanya untuk pengembangan—menggunakannya dalam produksi akan mencegah iOS mendeteksi file AASA Anda dengan benar, merusak fungsionalitas passkey.

Validasi: Gunakan Validator AASA Apple untuk memverifikasi konfigurasi Anda.

Android menggunakan Digital Asset Links untuk memverifikasi hubungan antara aplikasi dan situs web Anda.

Lokasi File: https://yourdomain.com/.well-known/assetlinks.json

Persyaratan Konfigurasi:

• Host di /.well-known/assetlinks.json di domain Anda
• Disajikan melalui HTTPS dengan sertifikat yang valid
• Content-Type: application/json
• Sertakan sidik jari SHA256 aplikasi Anda (dari sertifikat penandatanganan)

Contoh File assetlinks.json:

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.example.app",
            "sha256_cert_fingerprints": [
                "AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99"
            ]
        }
    }
]

Validasi: Gunakan Generator Digital Asset Links Google untuk membuat dan memverifikasi konfigurasi Anda.

Aplikasi iOS memerlukan entitlement yang tepat untuk mengakses fungsionalitas passkey. Persyaratannya berbeda sedikit berdasarkan pendekatan implementasi Anda.

File entitlement (sering dinamai Runner.entitlements di aplikasi Flutter atau YourApp.entitlements di proyek iOS native) mendefinisikan izin dan kapabilitas khusus yang diberikan oleh sistem Apple. Untuk passkey, file ini mengonfigurasi Associated Domains.

Lokasi File: Biasanya di proyek Xcode Anda di ios/Runner/Runner.entitlements

Implementasi Native dan Embedded WebView memerlukan kapabilitas Associated Domains untuk menghubungkan aplikasi Anda dengan domain web Anda. System WebView (ASWebAuthenticationSession) tidak memerlukan ini karena berjalan dalam konteks Safari.

Pengaturan di Xcode:

1. Buka proyek Anda di Xcode
2. Pilih target aplikasi Anda
3. Buka tab "Signing & Capabilities"
4. Klik "+ Capability" dan tambahkan "Associated Domains"
5. Tambahkan domain Anda dengan awalan webcredentials:

Contoh Konfigurasi:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>webcredentials:yourdomain.com</string>
        <string>webcredentials:subdomain.yourdomain.com</string>
    </array>
</dict>
</plist>

Beberapa Domain: Jika aplikasi Anda perlu bekerja dengan beberapa domain, Anda mungkin memerlukan Related Origin Requests (ROR).

Android Embedded WebView mendapatkan dukungan WebAuthn native dengan AndroidX WebKit 1.12, menghilangkan kebutuhan akan kode jembatan JavaScript kustom. System WebView (Chrome Custom Tabs) tidak memerlukan konfigurasi apa pun—kredensial bekerja secara otomatis.

Persyaratan:

• AndroidX WebKit 1.12.1 atau lebih baru (1.14.0+ direkomendasikan)
• Digital Asset Links dikonfigurasi
• APK WebView dengan dukungan WebAuthn (periksa melalui deteksi fitur)
• Catatan: Pustaka AndroidX Credentials TIDAK diperlukan untuk WebView WebAuthn, hanya untuk implementasi yang sepenuhnya native

Implementasi:

import androidx.webkit.WebSettingsCompat
import androidx.webkit.WebViewFeature
 
// Periksa apakah Otentikasi Web didukung
if (WebViewFeature.isFeatureSupported(WebViewFeature.WEB_AUTHENTICATION)) {
    // Aktifkan Otentikasi Web
    WebSettingsCompat.setWebAuthenticationSupport(
        webView.settings,
        WebSettingsCompat.WEB_AUTHENTICATION_SUPPORT_FOR_APP
    )
 
    // Aktifkan JavaScript
    webView.settings.javaScriptEnabled = true
}

Poin Kunci:

• Tidak perlu jembatan JavaScript: WebAuthn berfungsi secara native di WebView
• Deteksi fitur diperlukan: Selalu periksa WebViewFeature.WEB_AUTHENTICATION saat runtime
• Conditional UI tidak didukung: mediation:"conditional" (pengisian otomatis passkey di kolom input) tidak berfungsi di Embedded WebView
• Strategi fallback: Jika fitur tidak tersedia, gunakan Chrome Custom Tabs sebagai gantinya

Catatan Versi:

• Gunakan WebKit 1.12.1 atau lebih baru (1.12.0 memiliki masalah ketersediaan saat runtime)
• Dukungan fitur tergantung pada versi APK WebView pengguna - APK yang lebih lama di perangkat tidak akan mengekspos fitur tersebut

Sebelum AndroidX WebKit 1.12.0, dukungan WebAuthn native tidak ada di Embedded WebView. Tim harus:

1. Menggunakan Chrome Custom Tabs atau Auth Tab (direkomendasikan)
2. Membangun jembatan JavaScript kustom

Jika Anda perlu mendukung versi Android yang lebih lama atau perangkat tanpa APK WebView yang diperbarui, lihat panduan Integrasi WebView Credential Manager Android untuk pendekatan kode jembatan. Namun, kami sangat merekomendasikan penggunaan pendekatan native WebKit 1.12.1+ untuk aplikasi modern.

Rekomendasi: Gunakan dukungan WebAuthn native dengan AndroidX WebKit 1.12.1+. Jika tidak tersedia saat runtime, kembali ke Chrome Custom Tabs yang menyediakan dukungan passkey yang sangat baik dengan kredensial bersama.

Saat mengimplementasikan passkey di aplikasi native, Anda perlu membangun kepercayaan antara aplikasi Anda dan domain web. Bagian ini membahas cara menangani domain tunggal, beberapa domain terkait (ROR), dan cara memverifikasi file asosiasi well-known Anda dikonfigurasi dengan benar.

Untuk aplikasi yang menggunakan domain tunggal (mis. kayak.com), Anda memerlukan:

• Satu file AASA untuk iOS di https://kayak.com/.well-known/apple-app-site-association
• Satu assetlinks.json untuk Android di https://kayak.com/.well-known/assetlinks.json
• Entitlement Associated Domains dikonfigurasi dengan webcredentials:kayak.com

Related Origins (ROR) adalah fitur WebAuthn yang memungkinkan satu set passkey berfungsi di beberapa domain terkait (mis. kayak.com, kayak.de, kayak.co.uk). ROR menggunakan endpoint /.well-known/webauthn di setiap situs untuk mendefinisikan related origins, BUKAN file AASA atau assetlinks.

Poin Kunci:

• Konfigurasi ROR: Setiap domain menghosting /.well-known/webauthn dengan daftar related origins
• File asosiasi aplikasi (AASA/assetlinks): Hanya digunakan untuk memetakan aplikasi ke situs web yang sesuai
• iOS 18+ Embedded WebView: Mendukung ROR jika dikonfigurasi dengan benar
• Entitlement Associated Domains: Sertakan semua domain yang perlu diautentikasi oleh aplikasi Anda

Contoh Konfigurasi:

Jika aplikasi Anda bekerja dengan kayak.com dan kayak.de, kedua domain harus:

• Menghosting file AASA masing-masing dengan Team ID dan Bundle ID yang sama
• Terdaftar di entitlement Associated Domains aplikasi Anda
• Memiliki file well-known yang dikonfigurasi dan dapat diakses dengan benar

Sebelum ditayangkan, verifikasi file well-known Anda dikonfigurasi dan dapat diakses dengan benar. Apple dan Google menyediakan URL pengujian berbasis CDN untuk memeriksa ketersediaan file:

Menggunakan URL Pengujian Ini:

• Klik tautan untuk memverifikasi apakah Apple/Google dapat mengambil file well-known Anda
• Parameter ?nocache=1 Apple memaksa pengambilan ulang, melewati cache CDN
• Jika file tidak dapat diakses melalui URL ini, fungsionalitas passkey tidak akan berfungsi di aplikasi Anda
• Ganti kayak.com atau kayak.de dengan domain Anda sendiri di pola URL di atas

Kendala Pengujian: Pastikan semua domain memiliki file well-known yang dikonfigurasi dengan benar. Sebuah file yang hilang atau salah konfigurasi di domain mana pun dapat merusak fungsionalitas passkey untuk domain tersebut.

Informasi Lebih Lanjut: WebAuthn Relying Party ID di Aplikasi Native

Memilih pendekatan implementasi yang tepat tergantung pada arsitektur autentikasi aplikasi Anda, persyaratan OAuth, dan kebutuhan akan kontrol sesi. Gunakan pohon keputusan ini untuk menentukan jalur terbaik ke depan.

Mulailah dengan pertanyaan kunci ini:

1. Apakah aplikasi Anda menggunakan login berbasis OAuth (OAuth2, OIDC, penyedia social login)?

• Ya → System WebView (Bagian 1.2)
• iOS: Gunakan ASWebAuthenticationSession
• Android: Gunakan Chrome Custom Tabs
• Dukungan OAuth yang sangat baik dengan kredensial bersama

2. Apakah Anda ingin menggunakan kembali autentikasi web dalam shell seperti native (tanpa bilah URL, kontrol UI penuh)?

• Ya → Embedded WebView (Bagian 1.3) dengan konfigurasi
• iOS: WKWebView + entitlement Associated Domains
• Android: WebView + konfigurasi AndroidX WebKit 1.12.1+
• Memberikan tampilan seperti native sambil menggunakan kembali komponen web
• Catatan: Conditional UI tidak didukung di Embedded WebView
• Tidak → Pertimbangkan System WebView atau Native

3. Apakah Anda sedang membangun aplikasi native baru atau memiliki layar login native?

• Ya → Implementasi Native (Bagian 1.1)
• Pengalaman pengguna terbaik
• Autentikasi instan dan senyap
• Memerlukan pengembangan spesifik platform

4. Apakah Anda memiliki autentikasi web yang sudah ada yang ingin Anda gunakan kembali?

• Ya → System WebView untuk implementasi cepat
• Tidak → Implementasi Native untuk UX optimal

Berikut adalah bagaimana setiap pendekatan berkinerja di seluruh dimensi kunci:

Penjelasan Dimensi:

• Membuat Passkey: Seberapa mudah pengguna dapat membuat passkey melalui pendekatan ini
• Menggunakan Passkey: Pengalaman autentikasi saat menggunakan passkey yang ada
• Mengelola Passkey: Bagaimana pengguna melihat, mengedit, atau menghapus passkey
• Kompleksitas Teknis: Upaya pengembangan dan pemeliharaan berkelanjutan
• Dukungan OAuth: Seberapa baik pendekatan menangani alur autentikasi OAuth2/OIDC
• Waktu Penyiapan: Garis waktu implementasi tipikal

Direkomendasikan: System WebView

Jika aplikasi Anda mengautentikasi melalui OAuth2, OIDC, atau penyedia social login (Google, GitHub, Microsoft, dll.), System WebView adalah pilihan optimal:

• iOS: ASWebAuthenticationSession dibuat khusus untuk alur OAuth
• Android: Chrome Custom Tabs menyediakan integrasi OAuth yang mulus
• Manfaat: Kode native minimal, pembagian kredensial otomatis
• Implementasi: Tambahkan WebAuthn ke halaman autentikasi web Anda, lalu muat melalui System WebView

Contoh: Aplikasi travel seperti kayak.com dan kayak.de menggunakan OAuth untuk autentikasi. System WebView memungkinkan mereka untuk mempertahankan infrastruktur OAuth yang ada sambil menambahkan dukungan passkey melalui halaman autentikasi web mereka.

Direkomendasikan: Pendekatan Hibrida

Gunakan System WebView untuk autentikasi OAuth awal, lalu Embedded WebView untuk sesi pasca-autentikasi:

1. Autentikasi Awal: System WebView menangani login OAuth + passkey
2. Manajemen Sesi: Beralih ke Embedded WebView untuk konten web yang diautentikasi di mana Anda memerlukan kontrol cookie/sesi
3. Pengaturan Teknis: Konfigurasikan persyaratan System dan Embedded WebView—untuk Android, pastikan AndroidX WebKit 1.12.1+ disertakan (lihat Bagian 5)

Kapan digunakan: Aplikasi yang mengautentikasi melalui OAuth tetapi kemudian perlu menampilkan konten web yang diautentikasi di mana manipulasi sesi langsung diperlukan.

Direkomendasikan: Implementasi Native

Membangun dari awal atau memiliki layar native? Lakukan sepenuhnya native:

• iOS: Gunakan kerangka AuthenticationServices
• Android: Gunakan API Credential Manager
• Manfaat: UX terbaik, autentikasi instan, kontrol penuh
• Keuntungan Unik: Gunakan preferImmediatelyAvailableCredentials untuk menampilkan overlay passkey otomatis saat aplikasi dimulai - eksklusif untuk implementasi native dan memberikan tingkat konversi tertinggi
• Rekomendasi SDK: Gunakan SDK Corbado (iOS, Android) untuk mempercepat pengembangan dengan penanganan kasus khusus yang telah teruji produksi

Untuk Aplikasi Baru: Sangat merekomendasikan membangun login native sejak hari pertama. Ini menyiapkan Anda untuk UX optimal dan menghindari migrasi WebView-ke-native di masa depan.

Direkomendasikan: Migrasi Bertahap

• Fase 1: Passkey System WebView - Tambahkan dukungan passkey ke login web yang ada, muat melalui System WebView (ASWebAuthenticationSession/Chrome Custom Tabs). Kemenangan cepat dengan kode native minimal.
• Fase 2: Pencegatan Native - Tambahkan pemeriksaan passkey native sebelum menampilkan WebView. Contoh: kayak.com mencoba autentikasi passkey native terlebih dahulu, kembali ke WebView jika diperlukan. Menyediakan login biometrik cepat sambil mempertahankan kompatibilitas mundur.
• Fase 3: Sepenuhnya Native - Secara bertahap migrasi ke autentikasi native untuk pengguna passkey, menjaga WebView untuk metode lama.

Pendekatan bertahap ini memungkinkan perbaikan inkremental tanpa mengganggu pengguna yang ada.

Lihat Bagian 5 untuk instruksi konfigurasi terperinci.

Menguji passkey di aplikasi native memerlukan pendekatan terstruktur dan berlapis. Ikuti piramida pengujian: pengujian unit (logika terisolasi), pengujian integrasi (seremoni WebAuthn di simulator/emulator) dan pengujian sistem (end-to-end pada perangkat fisik).

Kategori Pengujian Esensial:

• Perjalanan Inti: Pendaftaran, autentikasi, alur lintas perangkat, penghapusan passkey
• Cakupan Platform: iOS (native), Android (native), browser web di berbagai versi OS
• Asosiasi Domain: Verifikasi file AASA (iOS) dan Digital Asset Links (Android) dapat diakses
• Alur Pembatalan: Uji pembatalan pengguna di prompt OS dan layar biometrik
• Penanganan Kesalahan: Kegagalan backend, batas waktu jaringan, ketidakcocokan kredensial
• Kasus Tepi: Kunci layar dinonaktifkan, iCloud/Google Password Manager dinonaktifkan
• Alur OAuth: Integrasi OAuth + passkey lengkap dari ujung ke ujung
• Perangkat Terkelola: Lingkungan yang dikontrol MDM (lihat pengujian perangkat terkelola)
• Pengelola Pihak Ketiga: Kompatibilitas 1Password, Bitwarden, Dashlane
• Autentikasi Lintas Perangkat: Alur kode QR dan pengujian transport hibrida
• Spesifik Embedded WebView: Jika menggunakan Embedded WebView, verifikasi konfigurasi WebKit 1.12.1+ di Android
• Pemantauan Produksi: Dasbor untuk tingkat keberhasilan, kegagalan, dan latensi

Untuk panduan pengujian komprehensif termasuk strategi otomatisasi, kendala spesifik platform, dan daftar periksa pra-penerbangan lengkap, lihat panduan khusus kami: Menguji Alur Passkey di Aplikasi iOS & Android Native.

Pertimbangkan untuk meminta pengguna membuat passkey setelah login tradisional yang berhasil (kata sandi, OAuth). Pendekatan konversi bertahap ini:

• Tidak mengganggu alur autentikasi yang ada
• Memungkinkan degradasi yang anggun jika pengguna menolak
• Meningkatkan adopsi passkey seiring waktu tanpa memaksakan perubahan
• Bekerja dengan baik dengan ketiga pendekatan implementasi

Contoh: Setelah login OAuth melalui System WebView, tampilkan prompt native: "Aktifkan login lebih cepat dengan Face ID?" Jika diterima, buat passkey melalui halaman web yang dimuat di System WebView.

Memutuskan cara mengimplementasikan passkey - melalui Implementasi Native, System WebView atau Embedded WebView adalah pilihan desain krusial yang memengaruhi keamanan, pengalaman pengguna, dan kompleksitas pengembangan. Tidak ada jawaban satu ukuran untuk semua.

Untuk aplikasi berbasis OAuth: System WebView (ASWebAuthenticationSession, Chrome Custom Tabs) adalah titik awal yang direkomendasikan. Ini memberikan dukungan OAuth yang sangat baik, upaya implementasi minimal, dan pembagian kredensial otomatis.

Untuk aplikasi yang mengutamakan native: Lakukan native lebih cepat daripada nanti. Login passkey native menawarkan UX paling mulus dengan kemampuan eksklusif seperti preferImmediatelyAvailableCredentials, yang memungkinkan overlay passkey otomatis saat aplikasi dimulai - sesuatu yang tidak dapat disediakan oleh implementasi WebView. Dengan iOS dan Android sekarang memberikan dukungan kelas satu untuk passkey, keberhasilan dunia nyata menunjukkan adopsi yang tinggi. Peralatan (termasuk SDK sumber terbuka dan pustaka platform) telah matang untuk membuat integrasi native dapat dicapai dalam kerangka waktu yang wajar. Meskipun Anda harus memperhatikan kebijakan manajemen perangkat, sinkronisasi lintas perangkat, dan penyedia pihak ketiga, tantangan-tantangan ini dapat dikelola dengan rekayasa dan pengujian yang cermat. Hasilnya adalah login aplikasi yang menyenangkan pengguna dengan kemudahan dan kecepatannya sambil meningkatkan keamanan secara signifikan.

Untuk persyaratan bingkai WebView tertanam: Embedded WebView umumnya digunakan dalam dua skenario dunia nyata. Pertama, aplikasi berbasis OAuth sering menggunakan System WebView untuk alur login awal, kemudian beralih ke Embedded WebView untuk merender opsi manajemen passkey di layar pengaturan di mana kontrol sesi diperlukan—meskipun beberapa aplikasi menyederhanakan ini dengan tetap menggunakan System WebView untuk kedua alur. Kedua, aplikasi yang sudah menyematkan alur autentikasi mereka di bingkai WebView sebelum mengadopsi passkey melanjutkan pola ini untuk konsistensi. Embedded WebView dengan dukungan WebAuthn native (AndroidX WebKit 1.12.1+) memerlukan konfigurasi dan penyiapan (izin, entitlement, pengaturan WebView) tetapi tidak lagi memerlukan kode jembatan JavaScript kustom. Perhatikan bahwa Conditional UI tidak didukung di Embedded WebView. Pilih pendekatan ini saat mempertahankan pola autentikasi tertanam yang ada atau saat Anda memerlukan kontrol sesi/cookie untuk layar pasca-autentikasi.

Pada akhirnya, passkey di aplikasi native merupakan lompatan besar ke depan dalam kenyamanan pengguna dan keamanan. Baik diimplementasikan melalui Native, System WebView, atau Embedded WebView, mereka menghilangkan risiko phising dan beban manajemen kata sandi untuk pengguna Anda. Implementasi dunia nyata seperti integrasi passkey aplikasi native VicRoads menunjukkan bahwa pendekatan yang mengutamakan native memberikan adopsi dan kepuasan pengguna tertinggi ketika dieksekusi dengan benar dengan fitur seperti overlay passkey otomatis. Mengikuti praktik terbaik untuk autentikasi yang ramah pengguna dan memilih pendekatan implementasi yang sesuai dengan arsitektur aplikasi Anda—mengutamakan native untuk aplikasi baru, System WebView untuk alur OAuth, atau Embedded WebView untuk pola tertanam yang ada—Anda dapat menawarkan login tanpa kata sandi dan biometrik yang benar-benar mewujudkan visi passkey: autentikasi yang sederhana, aman, dan menyenangkan untuk semua orang.

Jika passkey tidak berfungsi di aplikasi native Anda, periksa masalah umum ini berdasarkan pendekatan implementasi:

• File disajikan melalui HTTPS dengan sertifikat yang valid
• Tipe MIME yang benar: application/json
• Tidak ada pengalihan pada path .well-known
• iOS: Team ID dan Bundle ID cocok persis di file AASA
• Android: Sidik jari SHA256 cocok dengan sertifikat penandatanganan Anda di assetlinks.json
• Relying Party ID cocok dengan domain Anda (tanpa protokol, tanpa port)
• Tidak ada garis miring di akhir RP ID
• Origin WebAuthn: https://your-domain.com (bukan app://)

• iOS: Kapabilitas Associated Domains diaktifkan di Xcode dengan webcredentials:yourdomain.com
• Android: Digital Asset Links dideklarasikan di AndroidManifest.xml
• Pengguna mengaktifkan kunci layar (biometrik atau PIN)
• Uji dengan Validator AASA Apple dan alat Digital Asset Links Google
• Verifikasi file Runner.entitlements berisi domain terkait yang benar

• iOS: Menggunakan ASWebAuthenticationSession (direkomendasikan) atau SFSafariViewController
• Android: Menggunakan Chrome Custom Tabs (bukan WebView biasa)
• iOS: Verifikasi Associated Domains dikonfigurasi jika diperlukan
• Uji bahwa cookie/kredensial dibagikan dengan browser sistem
• Verifikasi halaman autentikasi web memiliki implementasi WebAuthn yang tepat

• iOS: Dikonfigurasi dengan entitlement yang tepat
• iOS: Associated Domains mencakup semua domain yang relevan
• iOS: File AASA dapat diakses dan diformat dengan benar
• iOS: Uji dengan ?mode=developer selama pengembangan (hapus untuk produksi)
• Android: AndroidX WebKit 1.12.1+ (atau lebih baru) disertakan dalam proyek
• Android: Pemeriksaan fitur runtime untuk WebViewFeature.WEB_AUTHENTICATION
• Android: setWebAuthenticationSupport() dipanggil dengan WEB_AUTHENTICATION_SUPPORT_FOR_APP
• Android: JavaScript diaktifkan di pengaturan WebView
• Android: Versi APK WebView pengguna mendukung fitur WebAuthn (gunakan deteksi fitur, bukan versi OS)
• Conditional UI tidak digunakan (tidak didukung di Embedded WebView)
• Kembali ke Chrome Custom Tabs jika fitur WebAuthn tidak tersedia

• Periksa apakah pengguna memiliki penyedia kredensial non-default yang aktif (1Password, Bitwarden, dll.)
• Verifikasi penyedia mendukung passkey (tidak semua pengelola kata sandi melakukannya)
• Uji dengan pengelola kredensial native platform (iCloud Keychain, Google Password Manager)

"NotAllowedError: The request is not allowed by the user agent or the platform in the current context"

• Biasanya berarti: Entitlement hilang (iOS) atau fitur WebView tidak tersedia/diaktifkan (Android Embedded WebView)
• Periksa: Konfigurasi Associated Domains, aksesibilitas file AASA, versi WebKit, deteksi fitur, panggilan setWebAuthenticationSupport()

Tidak ada prompt passkey yang muncul

• Bisa berarti: AASA/assetlinks.json tidak dimuat, jenis WebView salah, file AASA di-cache
• Coba: Validasi file asosiasi, gunakan ?mode=developer di iOS untuk pengujian, verifikasi jenis WebView

Untuk debugging terperinci, lihat artikel kami tentang ID Relying Party di aplikasi native.

SDK Native Corbado:

• SDK iOS (Swift)
• SDK Android (Kotlin)
• Paket Flutter

Dokumentasi Platform:

• Apple: Mendukung Passkey
• Google: Credential Manager

Alat Validasi:

• Validator AASA Apple
• Generator Digital Asset Links Google