klien rahasia OAuth 2.0
Untuk menggunakan google drive api, saya harus bermain dengan otentikasi menggunakan OAuth2.0. Dan saya punya beberapa pertanyaan tentang hal ini.
-
Id klien dan rahasia klien yang digunakan untuk mengidentifikasi apa app saya. Tapi mereka harus hardcoded jika itu adalah sebuah aplikasi klien. Jadi, semua orang dapat menguraikan aplikasi saya dan mengambil mereka dari kode sumber. Apakah itu berarti bahwa yang buruk, aplikasi yang bisa berpura-pura menjadi aplikasi yang baik dengan menggunakan aplikasi yang baik's id klien dan rahasia? Sehingga pengguna akan menampilkan layar yang meminta pemberian izin untuk aplikasi yang baik meskipun itu benar-benar diajukan oleh yang buruk app? Jika ya, apa yang harus saya lakukan? Atau sebenarnya aku tidak harus khawatir tentang hal ini?
-
Di aplikasi mobile, kita dapat tertanam webview app kami. Dan itu adalah mudah untuk mengekstrak kolom password di webview karena aplikasi yang meminta izin sebenarnya "browser". Jadi, OAuth di aplikasi mobile tidak memiliki manfaat yang aplikasi klien tidak memiliki akses untuk kredensial pengguna dari penyedia layanan?
Saya mulai menulis komentar pertanyaan anda tapi kemudian ternyata ada terlalu banyak untuk mengatakan jadi di sini adalah pandangan saya pada subjek dalam menjawab.
- Ya ada kemungkinan nyata untuk ini dan ada beberapa eksploitasi berdasarkan ini. Saran tidak untuk menjaga aplikasi rahasia dalam aplikasi anda, bahkan ada bagian di spec yang didistribusikan aplikasi tidak harus menggunakan token ini. Sekarang anda mungkin bertanya, tapi XYZ membutuhkan itu dalam rangka untuk bekerja. Dalam hal ini mereka tidak melaksanakan spec benar dan sebaiknya anda tidak menggunakan layanan tersebut (tidak mungkin) atau B mencoba untuk mengamankan token menggunakan beberapa obfuscating metode untuk membuat lebih sulit untuk menemukan atau menggunakan server sebagai proxy.
Misalnya ada beberapa bug di Facebook perpustakaan untuk Android di mana itu bocor token untuk Log, anda dapat mengetahui lebih lanjut tentang hal itu di sini http://attack-secure.com/all-your-facebook-access-tokens-are-belong-to-us dan di sini
Semua dalam semua harus ekstra hati-hati penggunaan anda dari perpustakaan pihak ketiga (common sense sebenarnya tapi jika token pembajakan adalah keprihatinan besar menambahkan tambahan lain untuk berhati-hati).- Saya telah mengomel tentang point 2 untuk beberapa waktu. Aku bahkan telah dilakukan beberapa workarounds di aplikasi saya dalam rangka untuk mengubah persetujuan halaman (misalnya mengubah zoom dan desain untuk cocok untuk aplikasi) tapi tidak ada yang menghentikan saya dari membaca nilai dari kolom dalam tampilan web dengan username dan password. Oleh karena itu saya setuju dengan poin kedua dan menemukan hal besar "bug" di OAuth spec. Intinya "App doesn't mendapatkan akses ke pengguna kredensial" di spec ini hanya mimpi dan memberikan pengguna rasa aman palsu... Juga saya kira, orang-orang biasanya kecurigaan ketika aplikasi meminta mereka untuk Facebook, Twitter, Dropbox atau kredensial lainnya. Aku yakin banyak orang-orang biasa baca OAuth spec dan mengatakan "Sekarang saya aman" tapi bukannya menggunakan akal sehat dan umumnya tidak menggunakan aplikasi yang mereka don't percaya.
Saya memiliki pertanyaan yang sama seperti pertanyaan 1 di sini, dan melakukan riset sendiri baru-baru ini, dan kesimpulan saya adalah bahwa itu adalah ok untuk tidak terus "rahasia klien" rahasia. Jenis klien yang tidak menjaga kerahasiaan klien rahasia yang disebut "umum klien" di OAuth2 spec. Kemungkinan seseorang yang berbahaya mampu untuk mendapatkan kode otorisasi, dan kemudian akses token, dicegah oleh fakta-fakta berikut.
-
Klien perlu untuk mendapatkan kode otorisasi langsung dari pengguna, bukan dari layanan
Bahkan jika pengguna menunjukkan layanan yang dia/dia percaya klien, klien tidak dapat mendapatkan kode otorisasi dari layanan hanya dengan menunjukkan id klien dan rahasia klien. Sebaliknya, para klien untuk mendapatkan kode otorisasi langsung dari pengguna. (Hal ini biasanya dilakukan dengan URL redirection, yang akan saya bicarakan nanti.) Jadi, untuk klien jahat, itu tidak cukup untuk mengetahui id klien/rahasia dipercaya oleh pengguna. Hal ini telah entah bagaimana melibatkan atau menipu pengguna untuk memberikan kode otorisasi, yang harus lebih keras dari sekedar mengetahui id klien/rahasia.
-
URL Redirect adalah terdaftar dengan id klien/rahasia
Mari kita berasumsi bahwa klien jahat entah bagaimana berhasil untuk melibatkan pengguna dan membuat dia/dia klik "Mengotorisasi aplikasi ini" tombol pada halaman layanan. Hal ini akan memicu URL redirect respon dari layanan untuk pengguna browser dengan kode otorisasi dengan itu. Kemudian kode otorisasi akan dikirim dari browser ke URL redirect, dan klien seharusnya mendengarkan di URL redirect untuk menerima kode otorisasi. (Redirect URL dapat localhost juga, dan saya pikir bahwa ini adalah cara khas yang "umum klien" menerima kode otorisasi.) Karena ini redirect URL terdaftar di layanan dengan klien id/rahasia, berbahaya klien tidak memiliki cara untuk mengontrol di mana kode otorisasi yang diberikan. Ini berarti berbahaya klien dengan klien anda id/rahasia memiliki kendala lain untuk memperoleh otorisasi pengguna kode.
Menjawab pertanyaan 2: Google Api untuk alasan keamanan mandat bahwa otentikasi/sign-in tidak dapat dilakukan dalam Aplikasi itu sendiri (seperti webviews tidak diperbolehkan) dan harus dilakukan di luar aplikasi menggunakan Browser untuk keamanan yang lebih baik yang selanjutnya akan dijelaskan di bawah ini: https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html
