rahasia klien di OAuth 2.0

95

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?

security  oauth  google-api  oauth-2.0 
— Beruang
sumber
2
Juga saya kira 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.
— Igor Čordaš
Benar-benar pertanyaan yang bagus pasti harus memiliki lebih banyak poin
— Shravan
Anda bisa mengunduh ClientId dan rahasia dari server Anda dan menyimpannya di gantungan kunci pada login pertama yang berhasil, itu saja
— Shravan
@Sharvan Saya mungkin salah tetapi menurut saya gantungan kunci rentan pada ponsel yang di-rooting, jadi rahasia klien Anda dapat dipublikasikan.
— chichilatte

Jawaban:

16

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.

— Igor Čordaš
sumber
3
ID klien dan rahasia klien Anda tidak akan aman hanya karena Anda mempostingnya di terowongan SSL. Ya, mereka lebih aman dari serangan manusia di tengah. Jika pengguna membuat proxy panggilan HTTP Anda, mereka dapat menerima sertifikat buruk dan melihat semua yang Anda posting. Ngomong-ngomong, ini adalah cara termudah untuk mencuri rahasia klien seseorang di perangkat seluler.
— EpicThreeDev
5
Saya menghargai komentar Anda tetapi tidak dapat menghubungkannya dengan jawaban saya dengan cara apa pun ... Bisakah Anda menjelaskan mengapa Anda mengomentari jawaban saya karena saya secara eksplisit menyatakan bahwa rahasia Klien tidak boleh digunakan dalam aplikasi terdistribusi dan poin lainnya adalah itu ada beberapa solusi untuk mendapatkan kredensial pengguna di aplikasi meskipun menggunakan OAuth sehingga pengguna harus mempercayai penyedia aplikasi dan bukan OAuth.
— Igor Čordaš
Juga saya tidak mengerti apa yang Anda maksud dengan "Jika pengguna membuat proxy panggilan HTTPs Anda" ya, pengguna mendapatkan akses ke data yang mereka kirim menggunakan HTTPs dan mereka bebas untuk panggilan proxy sesuka mereka. Seperti yang saya mengerti, Anda menyarankan ini sebagai alternatif yang cukup bagus untuk membongkar apk untuk mendapatkan rahasianya tetapi sekali lagi Anda tidak boleh mengirim rahasia aplikasi sejak awal.
— Igor Čordaš
Jadi untuk poin 1) aplikasi yang buruk perlu memiliki akses ke sistem yang sama dan mengambil token akses / penyegaran dari perangkat yang sama ?
— gauteh
Tidak jelas apa yang Anda anggap sebagai "sistem yang sama" dalam konteks ini. Aplikasi membuat tampilan web tempat halaman konfirmasi ditampilkan dan dapat mengakses semua data dalam tampilan tersebut (termasuk cookie atau parameter url yang menghosting token akses). Akses lintas aplikasi juga dimungkinkan dalam beberapa kasus, misalnya jika satu aplikasi dapat mengakses log aplikasi lain, ia dapat menemukan token di sana seperti yang disebutkan dengan bug fb lib.
— Igor Čordaš
16

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.

— hideaki
sumber
3
Ini menjanjikan, apakah Anda punya referensi untuk ini? Akan meyakinkan untuk mengetahuinya.
— gauteh
1
Saya melihat di dokumen Drive bahwa di aplikasi yang terinstal, rahasia klien sebenarnya bukan rahasia, tetapi mereka tidak menjelaskan mengapa tidak masalah untuk menyimpannya di sana. Penjelasan Anda sangat membantu!
— Martin Spasov
1

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

— vj
sumber
setidaknya itu "diperbaiki" 3 tahun setelah saya bertanya :)
— Bear
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.