Apa's hak OAuth 2.0 aliran untuk aplikasi mobile

Klarifikasi: Mobile Aplikasi = Aplikasi Asli Seperti yang dinyatakan di komentar lain dan beberapa sumber online, implisit sepertinya cocok alami untuk mobile apps, namun solusi yang terbaik tidak selalu jelas (dan pada kenyataannya implisit tidak dianjurkan untuk alasan yang dibahas di bawah). Aplikasi Asli OAuth2 Praktik Terbaik Apa pun pendekatan yang anda pilih (ada beberapa trade off untuk mempertimbangkan), anda harus membayar perhatian pada praktik-praktik terbaik seperti yang diuraikan di sini untuk Native Apps menggunakan OAuth2: https://tools.ietf.org/html/rfc8252 Pertimbangkan pilihan berikut Implisit Saya harus menggunakan implisit? Untuk kutipan dari Bagian 8.2 https://tools.ietf.org/html/rfc8252#section-8.2

OAuth 2.0 implisit memberikan otorisasi aliran (didefinisikan dalam Bagian 4.2 OAuth 2.0 [RFC6749]) umumnya bekerja dengan praktek melakukan permintaan otorisasi browser dan menerima otorisasi respon melalui URI berbasis inter-app komunikasi. Namun, seperti yang implisit aliran tidak dapat dilindungi oleh PKCE [RFC7636] (yang diperlukan di Bagian 8.1), penggunaan Implisit Aliran dengan aplikasi asli TIDAK DIANJURKAN. Akses token yang diberikan melalui implisit mengalir juga tidak bisa lebih segar tanpa interaksi pengguna, membuat kode otorisasi hibah mengalir ... yang dapat mengeluarkan refresh token -- dengan pilihan yang lebih praktis untuk aplikasi asli otorisasi yang memerlukan menyegarkan akses token. Kode Otorisasi Jika anda pergi dengan Kode Otorisasi, maka salah satu pendekatan yang akan melalui proxy server web anda sendiri komponen yang memperkaya token permintaan dengan rahasia klien untuk menghindari menyimpannya di didistribusikan aplikasi pada perangkat. Kutipan di bawah ini dari: https://dev.fitbit.com/docs/oauth2/ Kode Otorisasi Memberikan aliran dianjurkan untuk aplikasi yang memiliki layanan web. Aliran ini membutuhkan server-ke-server komunikasi menggunakan aplikasi's rahasia klien.

Note: jangan Pernah menaruh rahasia klien anda di didistribusikan kode, seperti aplikasi di-download melalui app store atau client-side JavaScript.

Aplikasi yang tidak memiliki layanan web harus menggunakan Implisit Hibah aliran. Kesimpulan Keputusan akhir harus faktor dalam yang anda inginkan pengalaman pengguna tapi juga nafsu makan anda untuk risiko setelah melakukan penilaian risiko yang tepat anda terpilih pendekatan dan pemahaman yang lebih baik implikasi. Baca di sini https://auth0.com/blog/oauth-2-best-practices-for-native-apps/ Satu lagi adalah https://www.oauth.com/oauth2-servers/oauth-native-apps/ yang menyatakan saat ini industri praktek terbaik adalah untuk menggunakan Otorisasi Aliran sementara menghilangkan rahasia klien, dan untuk menggunakan eksternal user agent untuk lengkap aliran. Pengguna eksternal agent biasanya perangkat browser asli, (dengan memisahkan domain keamanan dari aplikasi asli,) sehingga aplikasi tidak dapat mengakses penyimpanan cookie atau memeriksa atau mengubah halaman konten dalam browser. PKCE Pertimbangan Anda juga harus mempertimbangkan PKCE yang dijelaskan di sini https://www.oauth.com/oauth2-servers/pkce/ Secara khusus, jika anda juga melaksanakan Otorisasi Server maka https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ menyatakan bahwa anda harus

• Memungkinkan klien untuk mendaftarkan URL kustom skema untuk mereka redirect Url.
• Dukungan loopback IP redirect Url dengan sewenang-wenang nomor port dalam rangka mendukung aplikasi desktop.
• Jangan berasumsi aplikasi asli yang dapat menjaga rahasia. Memerlukan semua aplikasi untuk menyatakan apakah mereka adalah publik atau rahasia, dan hanya masalah klien rahasia untuk aplikasi rahasia.
• Mendukung PKCE ekstensi, dan mengharuskan semua klien menggunakannya.
• Upaya untuk mendeteksi ketika otorisasi antarmuka yang tertanam dalam aplikasi asli web view, bukannya diluncurkan dalam sistem browser, dan menolak permintaan tersebut. Tampilan Web Pertimbangan Ada banyak contoh di alam liar menggunakan Tampilan Web yaitu aplikasi yang tertanam user-agent tetapi pendekatan ini harus dihindari (terutama ketika aplikasi tidak pihak pertama) dan dalam beberapa kasus dapat mengakibatkan anda dilarang menggunakan API seperti kutipan di bawah ini dari di sini menunjukkan Setiap usaha untuk menanamkan otentikasi OAuth 2.0 halaman akan mengakibatkan aplikasi anda dilarang dari Fitbit API.

Untuk pertimbangan keamanan, OAuth 2.0 halaman otorisasi harus yang disajikan dalam browser khusus melihat. Fitbit pengguna hanya dapat mengkonfirmasi mereka otentikasi dengan yang asli Fitbit.com situs ini jika mereka memiliki alat-alat yang disediakan oleh browser, seperti URL bar dan Transportasi Layer Security (TLS) sertifikat informasi.

Untuk aplikasi asli, ini berarti halaman otorisasi harus terbuka di browser default. Aplikasi-aplikasi dapat menggunakan skema URL kustom sebagai redirect Uri untuk mengarahkan pengguna kembali dari browser ke aplikasi meminta izin.

aplikasi iOS dapat menggunakan SFSafariViewController kelas bukan aplikasi beralih ke Safari. Penggunaan WKWebView atau UIWebView kelas dilarang.

aplikasi Android dapat menggunakan Chrome Tab Kustom, bukan aplikasi beralih ke browser default. Menggunakan WebView adalah dilarang. Untuk lebih memperjelas, berikut ini adalah kutipan dari bagian dari sebelumnya rancangan terbaik berlatih link yang disediakan di atas Tertanam agen pengguna, umumnya diimplementasikan dengan web-pandangan, merupakan metode alternatif untuk mengotorisasi aplikasi asli. Namun mereka tidak aman untuk digunakan oleh pihak ketiga dengan definisi. Mereka melibatkan pengguna masuk dengan penuh mereka login, hanya untuk memiliki mereka downscoped kurang kuat OAuth kredensial.

Bahkan ketika digunakan oleh terpercaya pertama-party apps, tertanam user-agen melanggar prinsip dari least privilege dengan mendapatkan lebih kuat kredensial dari yang mereka butuhkan, yang berpotensi meningkatkan serangan permukaan.

khas web-view berdasarkan implementasi embedded user-agen aplikasi host dapat: log setiap keystroke yang dimasukkan dalam formulir menangkap username dan password, secara otomatis mengirimkan formulir dan bypass user-persetujuan; copy cookie sesi dan menggunakan mereka untuk melakukan dikonfirmasi tindakan sebagai pengguna.

Mendorong pengguna untuk memasukkan kredensial di web tertanam-lihat tanpa biasa address bar dan identitas lainnya browser memiliki fitur-fitur yang membuat tidak mungkin bagi pengguna untuk mengetahui jika mereka masuk ke situs yang sah, dan bahkan ketika mereka, melatih mereka bahwa itu's OK untuk memasukkan kredensial tanpa memvalidasi situs pertama.

Selain masalah keamanan, web-pandangan yang tidak berbagi otentikasi negara dengan aplikasi lain atau sistem browser, membutuhkan pengguna untuk login untuk setiap permintaan otorisasi dan mengarah ke pengalaman pengguna yang buruk.

Karena atas, penggunaan tertanam agen pengguna adalah TIDAK DIANJURKAN, kecuali terpercaya pertama-aplikasi pihak bertindak sebagai pengguna eksternal- agen untuk aplikasi lain, atau menyediakan single sign-on untuk beberapa pertama- aplikasi pihak.

Otorisasi server HARUS mempertimbangkan untuk mengambil langkah-langkah untuk mendeteksi dan memblokir login via tertanam agen pengguna yang tidak mereka sendiri, di mana mungkin. Beberapa poin yang menarik juga dibesarkan di sini: https://security.stackexchange.com/questions/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the-a

Sayangnya, saya don't pikir ada jawaban yang jelas untuk pertanyaan ini. Namun, di sini adalah pilihan yang saya've diidentifikasi:

• Jika itu adalah ok untuk meminta pengguna untuk/nya kredensial, kemudian gunakan Sumber daya Pemilik Sandi Kredensial. Namun, hal ini tidak mungkin untuk beberapa alasan, yaitu

• Kegunaan atau kebijakan keamanan melarang memasukkan password langsung di app

• Proses otentikasi adalah didelegasikan pada eksternal Identitas Penyedia dan harus dilakukan melalui HTTP redirect berbasis aliran (misalnya OpenID, SAMLP atau WS-Federation)

• Jika penggunaan browser berbasis aliran diperlukan, kemudian gunakan Kode Otorisasi Aliran. Di sini, definisi dari redirect_uri adalah sebuah tantangan besar, yang ada adalah pilihan berikut:

• Menggunakan teknik yang dijelaskan dalam https://developers.google.com/accounts/docs/OAuth2InstalledApp, di mana khusus redirect_uri (misalnya urn:ietf:wg:oauth:2.0:oob) sinyal otorisasi akhir untuk menunjukkan kode otorisasi, bukan mengarahkan kembali ke aplikasi client. Pengguna dapat secara manual copy kode ini atau aplikasi dapat mencoba untuk mendapatkan itu dari dokumen HTML judul.

• Menggunakan localhost server pada perangkat (port management mungkin tidak akan mudah).

• Menggunakan custom skema URI (misalnya myapp://...) bahwa ketika dereferenced memicu terdaftar "handler" (rincian bergantung pada platform mobile).

• Jika tersedia, gunakan pembersih khusus "tampilan web", seperti WebAuthenticationBroker pada Windows 8, untuk mengontrol dan mengakses HTTP redirect tanggapan.

Semoga ini bisa membantu

Pedro

TL;DR: Gunakan Kode Otorisasi Hibah dengan PKCE

1. Implisit Jenis Hibah

Implisit hibah jenis ini cukup populer dengan aplikasi mobile. Tapi itu tidak dimaksudkan untuk digunakan seperti ini. Ada kekhawatiran keamanan di seluruh mengarahkan. Justin Kaya serikat:

masalah datang ketika anda menyadari bahwa tidak seperti dengan remote server URL, tidak ada cara yang dapat diandalkan untuk memastikan bahwa pengikatan antara mengingat mengarahkan URI dan spesifik aplikasi mobile dihormati. Setiap aplikasi pada perangkat anda dapat mencoba untuk memasukkan dirinya ke dalam pengalihan proses dan menyebabkan itu untuk melayani mengarahkan URI. Dan coba tebak: jika anda telah menggunakan implisit aliran dalam aplikasi asli anda, maka anda hanya menyerahkan penyerang akses token anda. Tidak ada pemulihan dari saat itu — mereka punya token dan mereka dapat menggunakannya.

Dan bersama-sama dengan fakta, bahwa hal itu tidak membiarkan anda refresh token akses, lebih baik menghindarinya.

2. Kode Otorisasi Jenis Hibah

Kode otorisasi hibah memerlukan klien yang rahasia. Tapi anda tidak perlu menyimpan informasi yang sensitif dalam kode sumber dari aplikasi seluler anda. Orang-orang dapat mengambil mereka. Untuk tidak mengekspos rahasia klien, anda harus menjalankan server sebagai perantara sebagai Facebook menulis:

Kami merekomendasikan bahwa Aplikasi Akses Token hanya dapat digunakan langsung dari aplikasi's server dalam rangka untuk memberikan keamanan terbaik. Untuk asli aplikasi, kami sarankan bahwa aplikasi berkomunikasi dengan server anda sendiri dan server kemudian membuat permintaan API ke Facebook menggunakan Aplikasi Akses Token.

Bukan solusi yang ideal tapi ada yang baru, cara yang lebih baik untuk melakukan OAuth pada perangkat mobile: Bukti Kunci untuk Kode Exchange

3. Kode otorisasi Jenis Hibah dengan PKCE (Bukti Kunci untuk Kode Exchange)

Keluar dari keterbatasan, teknik baru dibuat yang memungkinkan anda menggunakan Kode Otorisasi tanpa rahasia klien. Anda dapat membaca penuh RFC 7636 atau pendahuluan singkat ini.

PKCE (RFC 7636) adalah teknik untuk mengamankan semua klien yang don't menggunakan sebuah rahasia klien.

Hal ini terutama digunakan oleh penduduk asli dan mobile apps, tapi teknik ini dapat dapat diterapkan untuk umum setiap klien juga. Hal ini membutuhkan tambahan dukungan oleh otorisasi server, sehingga hanya didukung pada penyedia tertentu.

dari https://oauth.net/2/pkce/

Menggunakan webview di aplikasi mobile anda harus menjadi cara yang terjangkau untuk melaksanakan OAuth2.0 protokol pada platform Android.

Adapun redirect_uri lapangan, saya pikir http://localhost adalah pilihan yang baik dan anda don't memiliki port HTTP server dalam aplikasi anda, karena anda dapat menimpa pelaksanaan onPageStarted fungsi WebViewClient kelas dan berhenti loading halaman web dari http://localhost setelah anda memeriksa url parameter.

public void onPageStarted(final WebView webView, final String url,
        final Bitmap favicon) {}

Halus pengalaman pengguna untuk otentikasi, dan yang paling mudah untuk menerapkan untuk menanamkan webview di aplikasi anda. Proses tanggapan yang diterima oleh webview dari otentikasi titik dan mendeteksi kesalahan (user membatalkan) atau persetujuan (dan ekstrak token dari parameter kueri url). Dan saya pikir anda benar-benar bisa melakukan itu di semua platform. Saya telah berhasil membuat karya ini sebagai berikut: ios, android, mac, windows store 8.1 apps, windows phone 8.1 aplikasi. Saya melakukan ini untuk layanan-layanan berikut: dropbox, google drive, onedrive, box, basecamp. Untuk non-platform windows, saya menggunakan Xamarin yang seharusnya tidak mengekspos seluruh platform Api tertentu, namun hal itu tidak mengekspos cukup untuk membuat ini mungkin. Sehingga hal ini cukup mudah diakses solusi, bahkan dari lintas platform perspektif, dan anda don't perlu khawatir tentang ui otentikasi bentuk.