rahasia klien di OAuth 2.0

Untuk menggunakan api google drive, saya harus bermain dengan otentikasi menggunakan OAuth2.0. Dan saya mendapat beberapa pertanyaan tentang ini.

1. ID klien dan rahasia klien digunakan untuk mengidentifikasi aplikasi saya. Tetapi mereka harus di-hardcode jika itu adalah aplikasi klien. Jadi, semua orang dapat mendekompilasi aplikasi saya dan mengekstraknya dari kode sumber. Apakah ini berarti bahwa aplikasi yang buruk dapat berpura-pura menjadi aplikasi yang baik dengan menggunakan rahasia dan id klien dari aplikasi tersebut? Jadi pengguna akan menampilkan layar yang meminta izin untuk aplikasi yang baik meskipun sebenarnya diminta oleh aplikasi yang buruk? Jika ya, apa yang harus saya lakukan? Atau sebenarnya saya tidak perlu khawatir tentang ini?

2. Dalam aplikasi seluler, kami dapat menyematkan tampilan web ke aplikasi kami. Dan mudah untuk mengekstrak bidang sandi di tampilan web karena aplikasi yang meminta izin sebenarnya adalah "browser". Jadi, OAuth dalam aplikasi seluler tidak memiliki manfaat bahwa aplikasi klien tidak memiliki akses ke kredensial pengguna penyedia layanan?

Saya mulai menulis komentar untuk pertanyaan Anda tetapi kemudian menemukan bahwa terlalu banyak yang bisa dikatakan jadi inilah pandangan saya tentang subjek dalam jawaban.

1. Ya, ada kemungkinan nyata untuk ini dan ada beberapa eksploitasi berdasarkan ini. Sarannya bukan untuk merahasiakan aplikasi di aplikasi Anda, bahkan ada bagian dalam spesifikasi yang menyatakan bahwa aplikasi yang didistribusikan tidak boleh menggunakan token ini. Sekarang Anda mungkin bertanya, tetapi XYZ membutuhkannya agar berfungsi. Dalam hal ini, mereka tidak mengimplementasikan spesifikasi dengan benar dan Anda sebaiknya A tidak menggunakan layanan itu (kemungkinan besar tidak) atau B mencoba mengamankan token menggunakan beberapa metode obfuscating untuk mempersulit pencarian atau penggunaan server Anda sebagai proxy.

   Misalnya ada beberapa bug di perpustakaan Facebook untuk Android yang membocorkan token ke Log, Anda dapat mengetahui selengkapnya di sini http://attack-secure.com/all-your-facebook-access-tokens-are-belong -kepada kami dan di sini https://www.youtube.com/watch?v=twyL7Uxe6sk . Semua dalam semua, berhati-hatilah dalam penggunaan perpustakaan pihak ketiga (akal sehat sebenarnya tetapi jika pembajakan token adalah perhatian besar Anda, tambahkan ekstra lain untuk berhati-hati).

2. Saya telah mengomel tentang poin 2 selama beberapa waktu. Saya bahkan telah melakukan beberapa solusi di aplikasi saya untuk mengubah halaman persetujuan (misalnya mengubah zoom dan desain agar sesuai dengan aplikasi) tetapi tidak ada yang menghentikan saya dari membaca nilai dari bidang di dalam tampilan web dengan nama pengguna dan kata sandi. Oleh karena itu saya sangat setuju dengan poin kedua Anda dan menganggapnya sebagai "bug" besar dalam spesifikasi OAuth. Intinya, "Aplikasi tidak mendapatkan akses ke kredensial pengguna" dalam spesifikasi hanyalah mimpi dan memberi pengguna rasa aman yang salah ... Juga saya rasa orang biasanya curiga ketika aplikasi meminta mereka untuk Facebook, Twitter, Dropbox atau kredensial lainnya. Saya ragu banyak orang biasa membaca spesifikasi OAuth dan mengatakan "Sekarang saya aman", tetapi menggunakan akal sehat dan umumnya tidak menggunakan aplikasi yang tidak mereka percayai.

Saya memiliki pertanyaan yang sama dengan pertanyaan 1 di sini, dan melakukan penelitian sendiri baru-baru ini, dan kesimpulan saya adalah tidak masalah untuk tidak merahasiakan "rahasia klien". Jenis klien yang tidak menjaga kerahasiaan rahasia klien disebut "klien publik" dalam spesifikasi OAuth2. Kemungkinan seseorang yang berniat jahat bisa mendapatkan kode otorisasi, dan kemudian mengakses token, dicegah oleh fakta-fakta berikut.

1. Klien perlu mendapatkan kode otorisasi langsung dari pengguna, bukan dari layanan

Bahkan jika pengguna menunjukkan layanan yang dia percayai klien, klien tidak bisa mendapatkan kode otorisasi dari layanan hanya dengan menunjukkan id klien dan rahasia klien. Sebaliknya, klien harus mendapatkan kode otorisasi langsung dari pengguna. (Ini biasanya dilakukan dengan pengalihan URL, yang akan saya bicarakan nanti.) Jadi, untuk klien jahat, tidak cukup hanya mengetahui id / rahasia klien yang dipercaya oleh pengguna. Itu harus melibatkan atau menipu pengguna untuk memberinya kode otorisasi, yang seharusnya lebih sulit daripada hanya mengetahui id / rahasia klien.

2. URL redirect terdaftar dengan id / rahasia klien

Mari kita asumsikan bahwa klien jahat entah bagaimana berhasil melibatkan pengguna dan membuatnya mengklik tombol "Otorisasi aplikasi ini" pada halaman layanan. Ini akan memicu respons pengalihan URL dari layanan ke browser pengguna dengan kode otorisasi bersamanya. Kemudian kode otorisasi akan dikirim dari browser pengguna ke URL pengalihan, dan klien seharusnya mendengarkan di URL pengalihan untuk menerima kode otorisasi. (URL pengalihan dapat menjadi localhost juga, dan saya pikir ini adalah cara umum yang "klien publik" menerima kode otorisasi.) Karena URL pengalihan ini terdaftar di layanan dengan id / rahasia klien, klien jahat tidak memiliki cara untuk mengontrol ke mana kode otorisasi diberikan.

Menjawab pertanyaan ke-2: Google API untuk alasan keamanan mengamanatkan bahwa otentikasi / masuk tidak dapat dilakukan dalam Aplikasi itu sendiri (seperti tampilan web tidak diperbolehkan) dan perlu dilakukan di luar aplikasi menggunakan Browser untuk keamanan yang lebih baik yang dijelaskan lebih lanjut di bawah ini: https: //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html