Apa alur OAuth 2.0 yang tepat untuk aplikasi seluler

89

Saya mencoba menerapkan otorisasi yang didelegasikan di API Web untuk aplikasi seluler menggunakan OAuth 2.0. Menurut spesifikasi, aliran pemberian implisit tidak mendukung token penyegaran, yang berarti setelah token akses diberikan untuk jangka waktu tertentu, pengguna harus memberikan izin ke aplikasi lagi setelah token kedaluwarsa atau dicabut.

Saya rasa ini adalah skenario yang bagus untuk beberapa kode javascript yang berjalan di browser seperti yang disebutkan dalam spesifikasi. Saya mencoba meminimalkan waktu pengguna harus memberikan izin ke aplikasi untuk mendapatkan token, jadi sepertinya alur Kode Otorisasi adalah opsi yang baik karena mendukung token penyegaran.

Namun, aliran ini tampaknya sangat bergantung pada browser web untuk melakukan pengalihan. Saya bertanya-tanya apakah aliran ini masih merupakan opsi yang baik untuk aplikasi seluler jika browser web tertanam digunakan. Atau haruskah saya mengikuti aliran implisit?

security  mobile  oauth-2.0 
— Pablo Cibraro
sumber
1
Pertanyaannya adalah - apakah ini seperti prioritas tertinggi bahwa pengguna tidak perlu lagi mengetikkan kata sandi setelah login pertama?
— hak istimewa
Ya, itulah kebutuhan saya. Pengguna harus mengetikkan kata sandi hanya sekali. Namun, saya tidak ingin menyiapkan token dengan masa hidup tak terbatas dan menyimpannya di aplikasi seluler, karena itu akan bertentangan dengan kemampuan mencabut token. (Kecuali saya menambahkan beberapa logika di aplikasi seluler untuk mendeteksi bahwa permintaan itu tidak sah, jadi saya meminta token baru setelah itu)
— Pablo Cibraro
1
Anda dapat menambahkan token dengan masa hidup tak terbatas dan tetap mencabutnya. Dan ya, logika aplikasi harus bisa mendeteksinya. RFC 6750 mendefinisikan cara untuk memeriksa apakah kesalahan disebabkan oleh token yang dicabut.
— Pedro Felix
1
Harap hindari tampilan web (kecuali Anda memiliki tumpukan penuh dan tidak menggunakan login sosial) yang membuka kemungkinan sandi dikompromikan. Ketika saya dimintai kredensial oleh agen pengguna tersemat pihak ketiga, saya akan mencopot pemasangan aplikasi. Beberapa API sekarang bahkan melarang integrasi seperti ini dev.fitbit.com/docs/oauth2 Saya telah memberikan jawaban lain untuk lebih memperjelas beberapa konsep ini ( stackoverflow.com/a/38582630/752167 )
— Matt C

Jawaban:

91

Klarifikasi: Aplikasi Seluler = Aplikasi Asli

Seperti yang dinyatakan dalam komentar lain dan beberapa sumber online, implisit tampaknya cocok secara alami untuk aplikasi seluler, namun solusi terbaik tidak selalu jelas (dan sebenarnya implisit tidak disarankan karena alasan yang dibahas di bawah).

Praktik Terbaik OAuth2 Aplikasi Asli

Apa pun pendekatan yang Anda pilih (ada beberapa kompromi untuk dipertimbangkan), Anda harus memperhatikan praktik terbaik seperti yang diuraikan di sini untuk Native Apps menggunakan OAuth2: https://tools.ietf.org/html/rfc8252

Pertimbangkan opsi berikut

Implisit

Haruskah saya menggunakan implisit?

Mengutip dari Bagian 8.2 https://tools.ietf.org/html/rfc8252#section-8.2

Alur otorisasi pemberian implisit OAuth 2.0 (dijelaskan di Bagian 4.2 dari OAuth 2.0 [RFC6749]) umumnya berfungsi dengan praktik menjalankan permintaan otorisasi di browser dan menerima respons otorisasi melalui komunikasi antar-aplikasi berbasis URI.
Namun, karena aliran implisit tidak dapat dilindungi oleh PKCE [RFC7636] (yang diwajibkan dalam Bagian 8.1), penggunaan Alur Implisit dengan aplikasi asli TIDAK DIANJURKAN .

Token akses yang diberikan melalui aliran implisit juga tidak dapat dimuat ulang tanpa interaksi pengguna, membuat aliran pemberian kode otorisasi - yang dapat mengeluarkan token penyegaran - opsi yang lebih praktis untuk otorisasi aplikasi asli yang memerlukan penyegaran token akses.

Kode Otorisasi

Jika Anda menggunakan Kode Otorisasi, salah satu pendekatannya adalah melakukan proxy melalui komponen server web Anda sendiri yang memperkaya permintaan token dengan rahasia klien untuk menghindari menyimpannya di aplikasi terdistribusi pada perangkat.

Kutipan di bawah ini dari: https://dev.fitbit.com/docs/oauth2/

Alur Hibah Kode Otorisasi direkomendasikan untuk aplikasi yang memiliki layanan web. Alur ini membutuhkan komunikasi server-ke-server menggunakan rahasia klien aplikasi.

Catatan: Jangan pernah meletakkan rahasia klien Anda dalam kode terdistribusi, seperti aplikasi yang diunduh melalui toko aplikasi atau JavaScript sisi klien.

Aplikasi yang tidak memiliki layanan web harus menggunakan aliran Hibah Implisit.

Kesimpulan

Keputusan akhir harus mempertimbangkan pengalaman pengguna yang Anda inginkan, tetapi juga selera Anda terhadap risiko setelah melakukan penilaian risiko yang tepat dari pendekatan yang Anda pilih dan pemahaman yang lebih baik tentang implikasinya.

Bacaan yang bagus ada di sini https://auth0.com/blog/oauth-2-best-practices-for-native-apps/

Yang lainnya adalah https://www.oauth.com/oauth2-servers/oauth-native-apps/ yang menyatakan

Praktik terbaik industri saat ini adalah menggunakan Alur Otorisasi sambil menghilangkan rahasia klien, dan menggunakan agen pengguna eksternal untuk menyelesaikan alur. Agen pengguna eksternal biasanya adalah browser asli perangkat, (dengan domain keamanan terpisah dari aplikasi asli,) sehingga aplikasi tidak dapat mengakses penyimpanan cookie atau memeriksa atau mengubah konten halaman di dalam browser.

Pertimbangan PKCE

Anda juga harus mempertimbangkan PKCE yang dijelaskan di sini https://www.oauth.com/oauth2-servers/pkce/

Secara khusus, jika Anda juga menerapkan Server Otorisasi, maka https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ menyatakan bahwa Anda harus

  • Izinkan klien untuk mendaftarkan skema URL khusus untuk URL pengalihan mereka.
  • Mendukung URL pengalihan IP loopback dengan nomor port arbitrer untuk mendukung aplikasi desktop.
  • Jangan menganggap aplikasi asli dapat menyimpan rahasia. Mewajibkan semua aplikasi untuk menyatakan apakah itu publik atau rahasia, dan hanya menerbitkan rahasia klien ke aplikasi rahasia.
  • Mendukung ekstensi PKCE, dan mewajibkan klien publik untuk menggunakannya.
  • Mencoba mendeteksi saat antarmuka otorisasi disematkan dalam tampilan web aplikasi asli, bukan diluncurkan di browser sistem, dan menolak permintaan tersebut.

Pertimbangan Tampilan Web

Ada banyak contoh di alam bebas menggunakan Tampilan Web yaitu agen pengguna yang disematkan tetapi pendekatan ini harus dihindari (terutama jika aplikasi bukan pihak pertama) dan dalam beberapa kasus dapat mengakibatkan Anda dilarang menggunakan API sebagai kutipan di bawah ini dari sini menunjukkan

Setiap upaya untuk menyematkan halaman otentikasi OAuth 2.0 akan mengakibatkan aplikasi Anda diblokir dari API Fitbit.

Untuk pertimbangan keamanan, halaman otorisasi OAuth 2.0 harus disajikan dalam tampilan browser khusus. Pengguna Fitbit hanya dapat mengonfirmasi bahwa mereka mengautentikasi dengan situs Fitbit.com asli jika mereka memiliki alat yang disediakan oleh browser, seperti bilah URL dan informasi sertifikat Transport Layer Security (TLS).

Untuk aplikasi asli, ini berarti halaman otorisasi harus dibuka di browser default. Aplikasi asli dapat menggunakan skema URL khusus sebagai URI pengalihan untuk mengarahkan pengguna kembali dari browser ke aplikasi yang meminta izin.

Aplikasi iOS dapat menggunakan kelas SFSafariViewController alih-alih pengalihan aplikasi ke Safari. Penggunaan kelas WKWebView atau UIWebView dilarang.

Aplikasi Android dapat menggunakan Tab Khusus Chrome alih-alih pengalihan aplikasi ke browser default. Penggunaan WebView dilarang.

Untuk memperjelas lebih lanjut, berikut adalah kutipan dari bagian draf sebelumnya dari tautan praktik terbaik yang disediakan di atas

Agen pengguna tersemat, biasanya diterapkan dengan tampilan web, merupakan metode alternatif untuk memberi otorisasi aplikasi asli. Namun, menurut definisi, mereka tidak aman untuk digunakan oleh pihak ketiga. Mereka melibatkan pengguna yang masuk dengan kredensial masuk lengkap mereka, hanya untuk menurunkan mereka ke kredensial OAuth yang kurang kuat.

Bahkan saat digunakan oleh aplikasi pihak pertama tepercaya, agen pengguna yang disematkan melanggar prinsip hak istimewa paling rendah dengan mendapatkan kredensial yang lebih kuat daripada yang mereka butuhkan, yang berpotensi meningkatkan permukaan serangan.

Dalam implementasi umum berbasis tampilan web dari agen pengguna tersemat, aplikasi host dapat: mencatat setiap penekanan tombol yang dimasukkan dalam formulir untuk menangkap nama pengguna dan sandi; mengirimkan formulir secara otomatis dan mengabaikan persetujuan pengguna; salin cookie sesi dan gunakan untuk melakukan tindakan terautentikasi sebagai pengguna.

Mendorong pengguna untuk memasukkan kredensial dalam tampilan web tersemat tanpa bilah alamat biasa dan fitur identitas lain yang dimiliki browser membuat pengguna tidak mungkin mengetahui apakah mereka masuk ke situs yang sah, dan bahkan saat mereka masuk, itu melatih mereka bahwa tidak masalah memasukkan kredensial tanpa memvalidasi situs terlebih dahulu.

Selain masalah keamanan, tampilan web tidak membagikan status autentikasi dengan aplikasi lain atau browser sistem, mengharuskan pengguna untuk masuk untuk setiap permintaan otorisasi dan menyebabkan pengalaman pengguna yang buruk.

Karena hal di atas, penggunaan agen pengguna tersemat TIDAK DIANJURKAN, kecuali jika aplikasi pihak pertama tepercaya bertindak sebagai agen pengguna eksternal untuk aplikasi lain, atau menyediakan sistem masuk tunggal untuk beberapa aplikasi pihak pertama.

Server otorisasi HARUS mempertimbangkan untuk mengambil langkah-langkah untuk mendeteksi dan memblokir login melalui agen pengguna tertanam yang bukan milik mereka, jika memungkinkan.

Beberapa poin menarik juga diangkat di sini: /security/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the- Sebuah

— Matt C
sumber
3
Google menghapus dukungan untuk tampilan web pada 20 April 2017 developers.googleblog.com/2016/08/…
— Matt C
FYI referensi dokumen di awal Jawaban ini jika tidak lagi draf OAuth 2.0 untuk Native Apps - tools.ietf.org/html/rfc8252
— Kostiantyn Sokolinskyi
Terima kasih @KostiantynSokolinsi, diedit sesuai dengan tautan untuk rfc yang bukan lagi draf
— Matt C
@MattC Apa cara terbaik untuk mengimplementasikan pendaftaran pengguna baru? Haruskah kami melakukannya di dalam aplikasi atau di IDP? Apakah mungkin untuk masuk otomatis ke daftar posting pengguna? stackoverflow.com/questions/60187173/…
— Yashvit
Maaf saya bingung tentang beberapa detail ... Bisakah Anda melihatnya? Terima kasih! tautan ---> stackoverflow.com/q/61313694/4619958
— ch271828n
25

Sayangnya, menurut saya tidak ada jawaban yang jelas untuk pertanyaan ini. Namun, berikut adalah opsi yang telah saya identifikasi:

  • Jika boleh meminta kredensial pengguna, maka gunakan Kredensial Sandi Pemilik Sumber Daya . Namun, ini mungkin tidak dapat dilakukan karena beberapa alasan, yaitu

    • Kebijakan kegunaan atau keamanan melarang penyisipan kata sandi langsung di aplikasi
    • Proses otentikasi didelegasikan pada Penyedia Identitas eksternal dan harus dilakukan melalui aliran berbasis pengalihan HTTP (misalnya OpenID, SAMLP atau WS-Federation)

  • Jika penggunaan aliran berbasis browser diperlukan, gunakan Alur Kode Otorisasi . Di sini, definisi redirect_uriadalah tantangan utama, yang memiliki pilihan berikut:

    • Gunakan teknik yang dijelaskan di https://developers.google.com/accounts/docs/OAuth2InstalledApp , dengan tanda khusus redirect_uri(misalnya urn:ietf:wg:oauth:2.0:oob) memberi sinyal pada titik akhir otorisasi untuk menampilkan kode otorisasi alih-alih mengalihkan kembali ke aplikasi klien. Pengguna dapat menyalin kode ini secara manual atau aplikasi dapat mencoba mendapatkannya dari judul dokumen HTML.
    • Gunakan localhostserver di perangkat (manajemen port mungkin tidak mudah).
    • Gunakan skema URI khusus (misalnya myapp://...) yang ketika dereferensi memicu "penangan" terdaftar (detailnya bergantung pada platform seluler).
    • Jika tersedia, gunakan "tampilan web" khusus, seperti WebAuthenticationBroker di Windows 8, untuk mengontrol dan mengakses tanggapan pengalihan HTTP.

Semoga ini membantu

Pedro

— Pedro Felix
sumber
Terima kasih Pedro atas masukannya !. Ya, sepertinya Alur Kode Otorisasi dengan skema URI khusus atau Tampilan Web tampaknya menjadi opsi terbaik di sini.
— Pablo Cibraro
1
Itu semua tergantung pada apakah Anda ingin klien mengetikkan kata sandi ke dalam tampilan web atau di aplikasi klien. Jika memungkinkan, saya lebih suka aplikasi klien - lalu segera tukar rahasianya dengan token akses / penyegaran.
— leastprivilege
Terima kasih Dominick !. Pelanggan saya menggunakan ADFS untuk mengotentikasi pengguna, jadi mereka ingin memasukkan kredensial di halaman login. Tampilan web akan berfungsi untuk mereka
— Pablo Cibraro
5
Saya ingin tahu mengapa Anda merekomendasikan "alur kode otorisasi"? Tidakkah Anda memerlukan client_secret dan client_id untuk menukar kode dengan access_token? Saya pikir aliran "implisit" dirancang untuk skenario ini, karena tidak memerlukan rahasia untuk disimpan di perangkat.
— Eugenio Pace
1
implisit tidak mendukung token penyegaran OOB. Dalam skenario Pablo - saya jelas akan merekomendasikan aliran RO. Kedengarannya seperti perusahaan menerapkan aplikasi pada backend perusahaan yang sama.
— hak istimewa paling rendah
9

TL; DR: Gunakan Hibah Kode Otorisasi dengan PKCE

1. Jenis Hibah Tersirat

Jenis hibah implisit cukup populer dengan aplikasi seluler. Tapi itu tidak dimaksudkan untuk digunakan seperti ini. Ada masalah keamanan seputar pengalihan. Justin Richer menyatakan :

Masalahnya muncul saat Anda menyadari bahwa tidak seperti URL server jarak jauh, tidak ada cara yang dapat diandalkan untuk memastikan bahwa pengikatan antara URI pengalihan yang diberikan dan aplikasi seluler tertentu dipatuhi. Aplikasi apa pun di perangkat dapat mencoba memasukkan dirinya sendiri ke dalam proses pengalihan dan menyebabkannya menyajikan URI pengalihan. Dan coba tebak: jika Anda telah menggunakan aliran implisit dalam aplikasi asli Anda, Anda baru saja menyerahkan token akses Anda kepada penyerang. Tidak ada pemulihan sejak saat itu - mereka memiliki token dan dapat menggunakannya.

Dan bersama dengan fakta, itu tidak memungkinkan Anda menyegarkan token akses, lebih baik hindari.

2. Jenis Pemberian Kode Otorisasi

Pemberian kode otorisasi membutuhkan rahasia klien. Tetapi Anda tidak boleh menyimpan informasi sensitif dalam kode sumber aplikasi seluler Anda. Orang bisa mengekstraknya. Untuk tidak mengungkap rahasia klien, Anda harus menjalankan server sebagai perantara seperti yang ditulis Facebook :

Kami merekomendasikan bahwa Token Akses Aplikasi hanya boleh digunakan langsung dari server aplikasi Anda untuk memberikan keamanan terbaik. Untuk aplikasi asli, kami menyarankan agar aplikasi tersebut berkomunikasi dengan server Anda sendiri dan server kemudian membuat permintaan API ke Facebook menggunakan App Access Token.

Bukan solusi yang ideal, tetapi ada cara baru yang lebih baik untuk melakukan OAuth di perangkat seluler: Kunci Bukti untuk Pertukaran Kode

3. Jenis Pemberian Kode Otorisasi dengan PKCE (Kunci Bukti untuk Pertukaran Kode)

Di luar batasan, teknik baru telah dibuat yang memungkinkan Anda menggunakan Kode Otorisasi tanpa rahasia klien. Anda dapat membaca RFC 7636 lengkap atau pengantar singkat ini .

PKCE (RFC 7636) adalah teknik untuk mengamankan klien publik yang tidak menggunakan rahasia klien.

Ini terutama digunakan oleh aplikasi asli dan seluler, tetapi teknik ini dapat diterapkan ke klien publik mana pun juga. Ini membutuhkan dukungan tambahan oleh server otorisasi, sehingga hanya didukung pada penyedia tertentu.

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

— Johannes Filter
sumber
-4

Menggunakan tampilan web di aplikasi seluler Anda harus menjadi cara yang terjangkau untuk menerapkan protokol OAuth2.0 di platform Android.

Adapun bidang redirect_uri, menurut saya http://localhostadalah pilihan yang baik dan Anda tidak perlu mem-port server HTTP di dalam aplikasi Anda, karena Anda dapat menimpa implementasi onPageStartedfungsi di WebViewClientkelas dan berhenti memuat halaman web http://localhostsetelah Anda memeriksa urlparameter.

public void onPageStarted(final WebView webView, final String url,
        final Bitmap favicon) {}
— Angin barat
sumber
3
Praktik terbaik untuk Aplikasi Asli yang menggunakan OAuth2: tools.ietf.org/html/draft-wdenniss-oauth-native-apps
— Matt C
1
Seperti yang dikatakan Matt C, di atas. Tampilan Web adalah ide yang buruk untuk aplikasi seluler - mereka tidak aman, memungkinkan aplikasi untuk mendapatkan akses ke kredensial (jadi tidak lebih aman dari RO) dan tidak mengizinkan pengguna untuk memverifikasi domain dan sertifikat TLS. Gunakan tipe pemberian Kode Auth dengan penangan URI khusus, dan pastikan Anda menggunakan Kode Bukti untuk Pertukaran Kunci (PKCE) untuk menghentikan aplikasi berbahaya di ponsel Anda yang mencegat kode autentikasi dan mendapatkan akses ke API Anda.
— ChrisC
2
Versi terbaru dari draf OAuth 2.0 untuk dokumen praktik terbaik Native Apps ada di tools.ietf.org/html/draft-ietf-oauth-native-apps
— Jeff Olson
-5

Pengalaman pengguna paling lancar untuk autentikasi, dan yang paling mudah diterapkan adalah dengan menyematkan tampilan web di aplikasi Anda. Memproses tanggapan yang diterima oleh tampilan web dari titik otentikasi dan mendeteksi kesalahan (pembatalan pengguna) atau persetujuan (dan ekstrak token dari parameter kueri url). Dan saya pikir Anda bisa melakukannya di semua platform. Saya telah berhasil membuat ini berfungsi untuk yang berikut: aplikasi ios, android, mac, windows store 8.1, aplikasi windows phone 8.1. Saya melakukan ini untuk layanan berikut: dropbox, google drive, onedrive, box, basecamp. Untuk platform non-windows, saya menggunakan Xamarin yang seharusnya tidak mengekspos seluruh API spesifik platform, namun itu cukup mengekspos untuk memungkinkan hal ini. Jadi ini adalah solusi yang cukup mudah diakses, bahkan dari perspektif lintas platform, dan Anda tidak

— Radu Simionescu
sumber
Sambil memberikan pengalaman pengguna yang nyaman, kami akan melihat industri menjauh dari pendekatan ini. Karena tampilan web membuka kemungkinan peretasan kata sandi, ketika saya dimintai kredensial oleh agen pengguna yang disematkan, saya akan mencopot pemasangan aplikasi. Beberapa API sekarang bahkan melarang integrasi seperti ini dev.fitbit.com/docs/oauth2
— Matt C
Praktik terbaik untuk Aplikasi Asli yang menggunakan OAuth2: tools.ietf.org/html/draft-wdenniss-oauth-native-apps
— Matt C
Saya tidak melihat bagaimana layanan berkemampuan oauth melarang pendekatan ini. Itu tidak terdeteksi dan aman ... Beberapa layanan yang diaktifkan oauth menyediakan klien khusus platform untuk memudahkan otentifikasi, dan klien semacam itu benar-benar melakukan apa yang telah saya jelaskan di sini (tunjukkan tampilan web tertanam dan lacak perubahan url). Praktik terbaik yang Anda tautkan, merekomendasikan hal yang sama: gunakan browser sistem atau tampilan web tersemat. Argumen apa yang Anda serang dari tanggapan saya? tidak jelas.
— Radu Simionescu
Tidak ada serangan yang dimaksudkan, hanya menyoroti masalah tersebut. Tautan tersebut mengatakan ada 2 pendekatan yang Anda sebutkan tetapi hanya agen pengguna eksternal yang dapat dianggap aman, khususnya dikatakan bahwa opsi untuk aplikasi asli adalah "melalui agen pengguna yang disematkan, atau agen pengguna eksternal. Dokumen ini merekomendasikan eksternal agen pengguna menyukai tab browser dalam aplikasi sebagai satu-satunya pilihan yang aman dan dapat digunakan untuk OAuth. "
— Matt C
Kutipan lebih lanjut "Dalam implementasi berbasis tampilan web tipikal dari agen pengguna yang disematkan, aplikasi host dapat: mencatat setiap penekanan tombol yang dimasukkan ke dalam formulir untuk menangkap nama pengguna dan kata sandi; secara otomatis mengirimkan formulir dan melewati persetujuan pengguna" ....... "penggunaan agen pengguna tersemat TIDAK DIANJURKAN, kecuali jika aplikasi pihak pertama tepercaya bertindak sebagai agen pengguna eksternal untuk aplikasi lain, atau menyediakan sistem masuk tunggal untuk beberapa aplikasi pihak pertama. Server otorisasi HARUS mempertimbangkan untuk mengambil langkah-langkah untuk mendeteksi dan memblokir proses masuk melalui agen pengguna tersemat yang bukan milik mereka, jika memungkinkan. "
— Matt C
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.