Bagaimana OAuth 2 berbeda dari OAuth 1?

Dalam istilah yang sangat sederhana, dapatkah seseorang menjelaskan perbedaan antara OAuth 2 dan OAuth 1?

Apakah OAuth 1 sudah usang sekarang? Haruskah kita menerapkan OAuth 2? Saya tidak melihat banyak implementasi OAuth 2; sebagian besar masih menggunakan OAuth 1, yang membuat saya ragu OAuth 2 siap digunakan. Apakah itu?

Eran Hammer-Lahav telah melakukan pekerjaan yang sangat baik dalam menjelaskan mayoritas perbedaan dalam artikelnya Memperkenalkan OAuth 2.0 . Untuk meringkas, berikut adalah perbedaan utama:

Lebih Banyak Arus OAuth untuk memungkinkan dukungan yang lebih baik untuk aplikasi berbasis non-browser. Ini adalah kritik utama terhadap OAuth dari aplikasi klien yang tidak berbasis browser. Misalnya, dalam OAuth 1.0, aplikasi desktop atau aplikasi ponsel harus mengarahkan pengguna untuk membuka browser mereka ke layanan yang diinginkan, mengotentikasi dengan layanan, dan menyalin token dari layanan kembali ke aplikasi. Kritik utama di sini bertentangan dengan pengalaman pengguna. Dengan OAuth 2.0, sekarang ada cara baru bagi aplikasi untuk mendapatkan otorisasi bagi pengguna.

OAuth 2.0 tidak lagi mengharuskan aplikasi klien memiliki kriptografi. Hal ini kembali ke API Auth Twitter lama, yang tidak memerlukan aplikasi untuk token hash HMAC dan string permintaan. Dengan OAuth 2.0, aplikasi dapat membuat permintaan hanya menggunakan token yang dikeluarkan melalui HTTPS.

Tanda tangan OAuth 2.0 jauh lebih mudah. Tidak ada lagi penguraian, penyortiran, atau penyandian khusus.

OAuth 2.0 Token akses "berumur pendek". Biasanya, token OAuth 1.0 Access dapat disimpan selama satu tahun atau lebih (Twitter tidak pernah membiarkannya kedaluwarsa). OAuth 2.0 memiliki gagasan tentang token penyegaran. Meskipun saya tidak sepenuhnya yakin apa ini, tebakan saya adalah bahwa token akses Anda dapat berumur pendek (yaitu sesi berbasis) sementara token penyegaran Anda bisa menjadi "waktu hidup". Anda akan menggunakan token penyegaran untuk mendapatkan token akses baru daripada meminta pengguna untuk mengotorisasi ulang aplikasi Anda.

Akhirnya, OAuth 2.0 dimaksudkan untuk memiliki pemisahan peran yang bersih antara server yang bertanggung jawab untuk menangani permintaan OAuth dan server yang menangani otorisasi pengguna. Informasi lebih lanjut tentang itu dirinci dalam artikel tersebut.

Saya melihat jawaban yang bagus di sini, tetapi yang saya lewatkan adalah beberapa diagram dan karena saya harus bekerja dengan Spring Framework saya menemukan penjelasan mereka .

Saya menemukan diagram berikut ini sangat berguna. Mereka menggambarkan perbedaan dalam komunikasi antara pihak-pihak dengan OAuth2 dan OAuth1.

OAuth 2

OAuth 1

Penjelasan sebelumnya semuanya terlalu rinci dan rumit IMO. Sederhananya, OAuth 2 mendelegasikan keamanan ke protokol HTTPS. OAuth 1 tidak memerlukan ini dan akibatnya memiliki metode alternatif untuk menghadapi berbagai serangan. Metode-metode ini membutuhkan aplikasi untuk terlibat dalam protokol keamanan tertentu yang rumit dan dapat sulit diimplementasikan. Oleh karena itu, lebih mudah untuk hanya mengandalkan HTTPS untuk keamanan sehingga pengembang aplikasi tidak perlu khawatir tentang hal itu.

Mengenai pertanyaan Anda yang lain, jawabannya tergantung. Beberapa layanan tidak ingin memerlukan penggunaan HTTPS, dikembangkan sebelum OAuth 2, atau memiliki beberapa persyaratan lain yang dapat mencegah mereka menggunakan OAuth 2. Selain itu, ada banyak perdebatan tentang protokol OAuth 2 itu sendiri. Seperti yang Anda lihat, Facebook, Google, dan beberapa lainnya masing-masing memiliki versi protokol yang sedikit berbeda. Jadi beberapa orang tetap menggunakan OAuth 1 karena lebih seragam di berbagai platform. Baru-baru ini, protokol OAuth 2 telah difinalisasi tetapi kami belum melihat bagaimana adopsi akan diambil.

Perhatikan ada argumen keamanan yang serius terhadap penggunaan Oauth 2:

satu artikel suram

dan yang lebih teknis

Perhatikan ini berasal dari penulis utama Oauth 2.

Poin-poin penting:

• Oauth 2 tidak menawarkan keamanan di atas SSL sementara Oauth 1 tidak bergantung pada transportasi.

• dalam arti SSL tidak aman karena server tidak memverifikasi koneksi dan perpustakaan klien umum membuatnya mudah untuk mengabaikan kegagalan.

  Masalah dengan SSL / TLS, adalah ketika Anda gagal memverifikasi sertifikat di sisi klien, koneksi masih berfungsi. Setiap kali mengabaikan kesalahan mengarah pada kesuksesan, pengembang akan melakukan hal itu. Server tidak memiliki cara untuk menegakkan verifikasi sertifikat, dan bahkan jika bisa, penyerang pasti tidak akan melakukannya.

• Anda dapat menghilangkan semua keamanan Anda, yang jauh lebih sulit dilakukan di OAuth 1.0:

  Masalah potensial umum kedua adalah kesalahan ketik. Apakah Anda menganggapnya sebagai desain yang tepat ketika menghilangkan satu karakter ('s' di 'https') mengosongkan seluruh keamanan token? Atau mungkin mengirim permintaan (melalui koneksi SSL / TLS yang valid dan terverifikasi) ke tujuan yang salah (katakan ' http://gacebook.com '?). Ingat, bisa menggunakan token pembawa OAuth dari baris perintah jelas merupakan advokat pembawa kasus penggunaan yang dipromosikan.

Keamanan protokol OAuth 1.0 ( RFC 5849 ) bergantung pada asumsi bahwa kunci rahasia yang tertanam dalam aplikasi klien dapat dirahasiakan. Namun, anggapan itu naif.

Dalam OAuth 2.0 ( RFC 6749 ), aplikasi klien naif seperti itu disebut klien rahasia . Di sisi lain, aplikasi klien di lingkungan di mana sulit untuk menjaga kerahasiaan kunci rahasia disebut klien publik . Lihat 2.1. Jenis Klien untuk detail.

Dalam hal itu, OAuth 1.0 adalah spesifikasi hanya untuk klien rahasia.

" OAuth 2.0 dan Jalan Menuju Neraka " mengatakan bahwa OAuth 2.0 kurang aman, tetapi tidak ada perbedaan praktis dalam tingkat keamanan antara klien OAuth 1.0 dan klien rahasia OAuth 2.0. OAuth 1.0 mengharuskan untuk menghitung tanda tangan, tetapi itu tidak meningkatkan keamanan jika sudah dipastikan bahwa kunci rahasia di sisi klien dapat dirahasiakan. Komputasi tanda tangan hanyalah perhitungan rumit tanpa peningkatan keamanan praktis. Maksud saya, dibandingkan dengan kesederhanaan bahwa klien OAuth 2.0 terhubung ke server lebih dari TLS dan hanya menyajikan client_iddan client_secret, tidak dapat dikatakan bahwa perhitungan rumit lebih baik dalam hal keamanan.

Selain itu, RFC 5849 (OAuth 1.0) tidak menyebutkan apa pun tentang pengalihan terbuka sementara RFC 6749 (OAuth 2.0) tidak menyebutkan apa pun . Artinya, oauth_callbackparameter OAuth 1.0 dapat menjadi lubang keamanan.

Oleh karena itu, saya tidak berpikir OAuth 1.0 lebih aman daripada OAuth 2.0.

Keamanan OAuth 1.0 bergantung pada perhitungan tanda tangan. Tanda tangan dihitung menggunakan kunci rahasia di mana kunci rahasia adalah kunci bersama untuk HMAC-SHA1 ( RFC 5849, 3.4.2 ) atau kunci pribadi untuk RSA-SHA1 ( RFC 5849, 3.4.3 ). Siapa pun yang mengetahui kunci rahasia dapat menghitung tanda tangan. Jadi, jika kunci rahasia dikompromikan, kompleksitas perhitungan tanda tangan tidak ada artinya namun kompleks.

Ini berarti keamanan OAuth 1.0 tidak bergantung pada kompleksitas dan logika perhitungan tanda tangan tetapi hanya pada kerahasiaan kunci rahasia. Dengan kata lain, apa yang diperlukan untuk keamanan OAuth 1.0 hanyalah syarat bahwa kunci rahasia dapat dirahasiakan. Ini mungkin terdengar ekstrim, tetapi perhitungan tanda tangan tidak menambah peningkatan keamanan jika kondisinya sudah terpenuhi.

Demikian juga, klien rahasia OAuth 2.0 mengandalkan kondisi yang sama. Jika kondisinya sudah terpenuhi, apakah ada masalah dalam membuat koneksi aman menggunakan TLS dan mengirim client_iddan client_secretke server otorisasi melalui koneksi aman? Apakah ada perbedaan besar dalam tingkat keamanan antara klien rahasia OAuth 1.0 dan OAuth 2.0 jika keduanya bergantung pada kondisi yang sama?

Saya tidak dapat menemukan alasan yang baik untuk OAuth 1.0 untuk menyalahkan OAuth 2.0. Faktanya adalah bahwa (1) OAuth 1.0 hanyalah spesifikasi hanya untuk klien rahasia dan (2) OAuth 2.0 telah menyederhanakan protokol untuk klien rahasia dan juga mendukung klien publik . Terlepas dari apakah itu dikenal baik atau tidak, aplikasi smartphone diklasifikasikan sebagai klien publik ( RFC 6749, 9 ), yang mendapat manfaat dari OAuth 2.0.

Tanda tangan OAuth 2.0 tidak diperlukan untuk panggilan API yang sebenarnya setelah token dibuat. Hanya memiliki satu token keamanan.

OAuth 1.0 mengharuskan klien untuk mengirim dua token keamanan untuk setiap panggilan API, dan menggunakan keduanya untuk menghasilkan tanda tangan. Ini membutuhkan titik akhir sumber daya yang dilindungi memiliki akses ke kredensial klien untuk memvalidasi permintaan.

Di sini dijelaskan perbedaan antara OAuth 1.0 dan 2.0 dan bagaimana keduanya bekerja.

OAuth 2 tampaknya hanya buang-buang waktu (dari mulut seseorang yang sangat terlibat di dalamnya):

https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

Dia mengatakan (diedit untuk singkatnya dan dicetak tebal untuk penekanan):

... Saya tidak dapat lagi dikaitkan dengan standar OAuth 2.0. Saya mengundurkan diri dari peran saya sebagai penulis utama dan editor, menarik nama saya dari spesifikasi, dan meninggalkan kelompok kerja. Menghapus nama saya dari dokumen yang telah saya susah payah kerjakan selama tiga tahun dan lebih dari dua lusin konsep tidak mudah. Memutuskan untuk pindah dari upaya yang telah saya pimpin selama lebih dari lima tahun sangat menyakitkan.

... Pada akhirnya, saya mencapai kesimpulan bahwa OAuth 2.0 adalah protokol yang buruk. WS- * buruk. Sudah cukup buruk sehingga saya tidak lagi ingin dikaitkan dengannya. ... Bila dibandingkan dengan OAuth 1.0, spesifikasi 2.0 lebih kompleks, lebih sedikit interoperable, kurang bermanfaat, lebih tidak lengkap, dan yang paling penting, kurang aman.

Untuk menjadi jelas, OAuth 2.0 di tangan pengembang dengan pemahaman yang mendalam tentang keamanan web kemungkinan akan menghasilkan implementasi yang aman. Namun, di tangan sebagian besar pengembang - seperti pengalaman dua tahun terakhir - 2.0 cenderung menghasilkan implementasi yang tidak aman.

Jika Anda memerlukan penjelasan lanjutan, Anda perlu membaca kedua spesifikasi:

https://oauth.net/core/1.0a/

https://oauth.net/2/

Jika Anda membutuhkan penjelasan yang jelas tentang perbedaan aliran, ini dapat membantu Anda:

OAuth 1.0 Flow

1. Aplikasi klien mendaftar dengan penyedia, seperti Twitter.
2. Twitter memberikan "rahasia konsumen" kepada klien yang unik untuk aplikasi itu.
3. Aplikasi klien menandatangani semua permintaan OAuth ke Twitter dengan "rahasia konsumen" yang unik .
4. Jika ada permintaan OAuth yang salah, data hilang, atau ditandatangani dengan tidak benar, permintaan tersebut akan ditolak.

OAuth 2.0 Flow

1. Aplikasi klien mendaftar dengan penyedia, seperti Twitter.
2. Twitter memberi "rahasia klien" yang unik untuk aplikasi itu.
3. Aplikasi klien termasuk "rahasia klien" dengan setiap permintaan umumnya sebagai header http.
4. Jika ada permintaan OAuth yang salah, data hilang, atau mengandung rahasia yang salah, permintaan tersebut akan ditolak.

Sumber: https://codiscope.com/oauth-2-0-vs-oauth-1-0/

OAuth 2.0 berjanji untuk menyederhanakan hal-hal dengan cara berikut:

1. SSL diperlukan untuk semua komunikasi yang diperlukan untuk menghasilkan token. Ini adalah penurunan besar dalam kompleksitas karena tanda tangan kompleks itu tidak lagi diperlukan.
2. Tanda tangan tidak diperlukan untuk panggilan API yang sebenarnya setelah token dibuat - SSL juga sangat disarankan di sini.
3. Setelah token dibuat, OAuth 1.0 mengharuskan klien mengirim dua token keamanan pada setiap panggilan API, dan menggunakan keduanya untuk menghasilkan tanda tangan. OAuth 2.0 hanya memiliki satu token keamanan, dan tidak ada tanda tangan yang diperlukan.
4. Secara jelas ditentukan bagian protokol mana yang diimplementasikan oleh "pemilik sumber daya," yang merupakan server aktual yang mengimplementasikan API, dan bagian mana yang dapat diimplementasikan oleh "server otorisasi" yang terpisah. Itu akan membuatnya lebih mudah bagi produk-produk seperti Apigee untuk menawarkan dukungan OAuth 2.0 ke API yang ada.

Sumber: http://blog.apigee.com/detail/oauth_differences

Dari sudut pandang keamanan, saya akan memilih OAuth 1. Lihat OAuth 2.0 dan jalan menuju neraka

kutipan dari tautan itu: "Jika Anda saat ini berhasil menggunakan 1.0, abaikan 2.0. Ini tidak menawarkan nilai nyata di atas 1.0 (saya menduga pengembang klien Anda sudah menemukan tanda tangan 1,0 sekarang)

Jika Anda baru mengenal ruang ini, dan anggap diri Anda seorang pakar keamanan, gunakan 2.0 setelah memeriksa fitur-fiturnya dengan cermat. Jika Anda bukan seorang ahli, gunakan 1.0 atau salin implementasi 2.0 dari penyedia yang Anda percaya untuk memperbaikinya (dokumen API Facebook adalah tempat yang baik untuk memulai). 2.0 lebih baik untuk skala besar, tetapi jika Anda menjalankan operasi besar, Anda mungkin memiliki beberapa pakar keamanan di lokasi untuk mengetahui semuanya untuk Anda. "