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.
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 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.
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.
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