Aplikasi seluler menggunakan browser terintegrasi untuk membuat pengguna tetap bertahan pada ekosistem aplikasi dan meningkatkan pengalaman mereka. Browser ini memungkinkan orang untuk melihat konten web tanpa meninggalkan aplikasi. Ketika pengguna pergi ke browser eksternal untuk melihat konten web, mereka dapat dialihkan oleh hal -hal lain. Browser terintegrasi memberi pengguna fitur navigasi sederhana tanpa semua lonceng dan peluit browser penuh.

Cordova inappbrowser

Plugin InAppBrowser untuk Cordova membuat jendela browser terpisah yang berfungsi dengan sendirinya dari webview utama Cordova. Jendela ini bertindak sebagai browser web biasa, tetapi dengan perbedaan utama: ia tidak dapat mengakses API Cordova. Pemisahan ini menjadikannya pilihan yang baik untuk memuat konten pihak ketiga (tidak dapat diandalkan), karena menambahkan lapisan pelindung tambahan dibandingkan dengan pemuatan konten ini secara langsung di webview utama Cordova.

Berikut adalah karakteristik utama dari inappbrowser:

• Kebebasan Daftar Putih. Inappbrowser tidak harus mengikuti kebijakan keamanan aplikasi atau daftar putih, tidak seperti tampilan web utama.
• Navigasi otonom. Inappbrowser menyimpan tautan itu sendiri alih -alih mengirimnya ke browser default perangkat.
• Manajemen Sesi. Inappbrowser menghapus sesi dan cache saat Anda menutup dan meraih aplikasi. Tetapi jika Anda meletakkan aplikasi di latar belakang dan membawanya kembali, inappbrowser menjaga sesi. Pendekatan ini menetapkan keseimbangan antara memelihara data pengguna selama penggunaan normal aplikasi dan perlindungan kerahasiaan ketika aplikasi berhenti.

Tantangan dengan cordova inappbrowser

Ketika aplikasi seluler menggunakan plugin inappbrowser Cordova untuk meluncurkan tautan web, seperti yang diperlukan untuk koneksi tunggal (SSO), mereka menabrak bendungan jalan. Ketika kami mencoba mengintegrasikannya dengan Google dari Google, kami mengalami masalah. Inappbrowser tidak membuka URL koneksi Google karena standar keamanan yang sulit yang diikuti Google untuk OAuth 2.0.

Aturan keselamatan Google menyarankan menggunakan browser sistem, yang lebih aman. Kalau tidak, kita dapat menggunakan solusi lain seperti asweauthentication pada iOS, yang secara khusus dirancang untuk tanda OAuth 2.0.

Mengapa Cordova Inappbrowser tidak bekerja dengan Google IDP

Cordova Inappbrowser menggunakan WKWebView di iOS, sebuah webview yang dipersonalisasi. Tampilan ini memungkinkan pengembang untuk mengikuti perubahan URL, melihat tindakan pengguna dan menambahkan skrip, antara lain. Fitur -fitur ini mengkhawatirkan Google of Security, yang membuat Cordova InAppbrowser tidak pantas untuk login Google.

Google sekarang melarang permintaan oAuth di browser terintegrasi (tampilan web) karena pengalaman pengguna dan masalah keamanan. Sebagai gantinya, Google menyarankan menggunakan tab Browser atau Browser di aplikasi OAuth. Di iOS, ini berarti penggunaan sfsafarviewecontroller, bukan wkwebview, untuk membuat jurnalisasi lebih aman dan lebih mudah bagi pengguna.

Masalah ini berasal dari aturan keselamatan Google, yang membutuhkan fitur -fitur tertentu dan menjamin bahwa Inapbrower mungkin tidak menawarkan. Untuk mengatasi masalah ini, produsen aplikasi mungkin harus mempertimbangkan cara lain untuk menghubungkan atau menggunakan solusi yang dibuat untuk platform tertentu seperti asweauthentication untuk iOS, yang dirancang untuk mengelola proses koneksi yang aman.

Kapasitor Inappbrower

Apple terus memperbarui produk dan teknologinya. Ini membantu, tetapi dapat menciptakan masalah bagi pengembang.

Apple tidak lagi mendukung UIWebView dan akan segera menolak tawaran App Store yang menggunakannya. Pengembang harus menggunakan WKWebVie untuk menambahkan konten web ke aplikasi mereka.

InAppBrowser dari kapasitor menggunakan WKWebView di iOS dan WebView di Android. Di iOS, ia menggunakan sfsafariviewController, yang memenuhi kebutuhan layanan OAuth. Konfigurasi ini hanya memiliki headphone acara dasar untuk tindakan browser, yang membuatnya lebih aman.

Pendekatan kapasitor lebih baru dan menawarkan lebih banyak opsi untuk ditampilkan dan berinteraksi dengan konten. Ini bekerja dengan iOS dan Android, dan juga mendukung aplikasi web progresif (PWAS) dan aplikasi elektronik.

Tantangan browser capper

Tautan universal mungkin tidak berfungsi seperti yang dapat Anda bayangkan di versi Android dan iOS tertentu ketika Anda menggunakan InAppbrowser. Ini terjadi karena inappbrowser berjalan di kotak pasir webview, potong dari aplikasi utama untuk menjaga hal -hal aman. Pemisahan ini mencegah pandangan web dari mengakses fitur aplikasi asli yang memerlukan tautan universal untuk beroperasi.

Alih -alih tautan universal untuk aliran koneksi, aplikasi ion dapat mengonfigurasi diagram URL yang dipersonalisasi dengan PKCE (bukti untuk pertukaran kode). Metode ini menawarkan cara yang pasti untuk mengelola koneksi sambil berfungsi tentu saja pada platform yang berbeda.

Diagram URL yang dipersonalisasi untuk OAuth 2.0 dalam aplikasi seluler

Banyak platform seluler dan kantor mendukung komunikasi antar aplikasi melalui URI dengan memungkinkan aplikasi untuk merekam diagram URL yang dipersonalisasi. Pola -pola ini, seperti “com. Example.app”, memungkinkan aplikasi untuk mengelola permintaan URI tertentu.

Untuk mengimplementasikan permintaan otorisasi OAuth 2.0 dengan diagram URL yang dipersonalisasi. Aplikasi seluler membuka browser yang terintegrasi ke dalam permintaan otorisasi. Pengalihan URI dalam permintaan otorisasi menggunakan skema URL yang dipersonalisasi yang disimpan dari sistem operasi.

Saat memilih diagram URI, periksa apakah diagram didasarkan pada nama domain di bawah kendali Anda dan digunakan dalam urutan yang berlawanan. Situs web / aplikasi yang memiliki myapp.customurl.com harus digunakan com.customurl.myapp Seperti rencananya. Cobalah untuk menghindari menggunakan pola generik seperti “myApp” karena mereka tidak memenuhi persyaratan nama domain. Beberapa aplikasi yang dikelola oleh penerbit yang sama harus memastikan bahwa setiap skema unik dalam grup ini.

Contoh URI pengalihan menggunakan skema URL yang dipersonalisasi: com.example.app:/oauth2redirect/example-provider.

Berikut adalah aliran otorisasi untuk skema URL yang dipersonalisasi:

• Server otorisasi akan mengarahkan kembali ke pengalihan pelanggan URI setelah otentikasi yang berhasil.
• Sistem operasi meluncurkan aplikasi seluler URL akan ditransmisikan ke earphone aplikasi.
• Aplikasi seluler akan menangani pengalihan URI untuk mengekstrak kode otorisasi dan parameter lainnya.

Pola URL yang dipersonalisasi menawarkan cara transparan untuk mengelola aliran OAuth 2.0 dalam aplikasi seluler, meningkatkan pengalaman pengguna dengan memungkinkan navigasi langsung dalam aplikasi

iOS

Jika beberapa aplikasi merekam skema URL pribadi yang sama, IOS tidak mencegah diagram yang dipanggil. Sebaliknya, itu menjadi tidak terbatas aplikasi mana yang akan diluncurkan ketika diagram dipanggil.

Untuk informasi lebih lanjut, lihat Dokumentasi Apple.

Android

Ketika beberapa aplikasi mendaftar untuk skema URL pribadi yang sama di Android, sistem menampilkan kotak dialog pemilih pengguna, yang memungkinkan mereka untuk memilih aplikasi mana yang harus mengelola URL. Perilaku ini memberikan lebih banyak kontrol kepada pengguna tetapi selalu dapat menimbulkan risiko keamanan.

Untuk informasi lebih lanjut, lihat Dokumentasi Android.

PKCE (Kunci Bukti untuk Pertukaran Kode)

Aplikasi seluler harus menerapkan bukti untuk ekstensi pertukaran kode ke OAuth, dan penyedia identitas harus memberikan dukungan untuk PKCE.

PKCE adalah protokol yang digunakan dalam otorisasi OAuth 2.0 untuk memastikan bahwa pelanggan yang memprakarsai otorisasi menerima kode otorisasi. Ini berfungsi sebagai berikut:

• Aplikasi klien menghasilkan rantai acak secara kriptografis yang disebut “kode verifier”.
• Pelanggan membuat “tantangan kode” dengan mengubah verifikasi kode, umumnya menggunakan algoritma hash SHA-256.
• Pelanggan mengirimkan tantangan kode dengan permintaan otorisasi ke penyedia identitas.
• Penyedia identitas menyimpan tantangan kode dan mengeluarkan kode otorisasi.
• Saat bertukar kode otorisasi untuk token, pelanggan mengirim auditor kode asli.
• Pemasok identitas memeriksa apakah auditor kode sesuai dengan tantangan kode asli.

Proses ini akan memastikan bahwa hanya pelanggan asli yang dapat mengakses kode otorisasi, karena bagian intersepsi tidak akan memiliki auditor kode. PKCE sekarang direkomendasikan untuk semua pelanggan OAuth menggunakan aliran kode otorisasi.

AswebAuthenticaticessession

AswebAuthenticationSesse menawarkan beberapa keunggulan dibandingkan dengan browser kapasitor untuk aliran otentikasi:

AswebAuthenticationsesse dirancang khusus untuk otentikasi dan mematuhi persyaratan OAuth. Dalam proses peninjauan aplikasi Apple, Apple lebih suka mengimplementasikan otentikasi menggunakan AswebAuthenticationssession.

AswebAuthenticationSse berbagi lembar situs web dengan browser safari dan aplikasi seluler. Ini akan menawarkan pengalaman koneksi yang unik tanpa jahitan pada aplikasi seluler dan browser. Ini berbagi cookie dan memungkinkan penyelesaian kata sandi secara otomatis, meningkatkan kerevongan.

Sementara plugin browser terintegrasi lainnya menawarkan kompatibilitas multiplatform, AswebAuthenticationSSSesse memberikan solusi yang lebih aman dan ramah pengguna untuk iOS.

Kesimpulan

Implementasi aliran otorisasi OAuth dalam aplikasi seluler memerlukan pemeriksaan keamanan yang cermat dan praktik terbaik khusus untuk platform. Meskipun Cordova Inprower tidak lagi direkomendasikan karena masalah keamanan, pengembang memiliki alternatif yang dapat diandalkan lainnya.

Untuk iOS, aswebAuthenticationsessession lebih disukai untuk aliran OAuth, menawarkan peningkatan keamanan dan integrasi transparan dengan sistem operasi. Untuk Android, plugin Capacitor InAppBrowser menyediakan solusi yang layak untuk mengimplementasikan proses otentikasi yang aman.

Namun, untuk tampilan umum konten di luar aliran otentikasi, plugin browser kapasitor dibedakan sebagai opsi yang lebih fleksibel dan sesuai untuk iOS dan Android.