OAuth 2.0: Manfaat dan kasus penggunaan - mengapa?

Adakah yang bisa menjelaskan apa yang baik tentang OAuth2 dan mengapa kita harus menerapkannya? Saya bertanya karena saya agak bingung tentang hal itu - inilah pemikiran saya saat ini:

Permintaan OAuth1 (lebih tepatnya HMAC) tampak logis, mudah dimengerti, mudah dikembangkan dan benar-benar aman.

OAuth2, sebaliknya, membawa permintaan otorisasi, token akses dan menyegarkan token, dan Anda harus membuat 3 permintaan di awal sesi untuk mendapatkan data yang Anda cari. Dan bahkan kemudian, salah satu permintaan Anda pada akhirnya akan gagal ketika token berakhir.

Dan untuk mendapatkan token akses lain, Anda menggunakan token penyegaran yang disahkan bersamaan dengan token akses. Apakah itu membuat token akses menjadi sia-sia dari sudut pandang keamanan?

Plus, seperti yang telah ditunjukkan oleh / r / netsec baru-baru ini, SSL tidak semuanya sepenuhnya aman, jadi dorongan untuk mendapatkan semuanya ke TLS / SSL bukannya HMAC yang aman membingungkan saya.

OAuth berpendapat bahwa ini bukan tentang keamanan 100%, tetapi mempublikasikan dan menyelesaikannya. Itu tidak terdengar menjanjikan dari sudut pandang penyedia layanan. Saya bisa melihat apa yang coba dicapai oleh draft ketika menyebutkan 6 aliran yang berbeda, tapi itu tidak cocok bersama di kepala saya.

Saya pikir mungkin lebih sulit bagi saya untuk memahami manfaat dan alasannya daripada benar-benar tidak menyukainya, jadi ini mungkin sedikit serangan yang tidak beralasan, dan maaf jika ini bisa terlihat seperti kata-kata kasar.

Latar Belakang: Saya sudah menulis tumpukan klien dan server untuk OAuth 1.0a dan 2.0.

Baik OAuth 1.0a & 2.0 mendukung otentikasi dua-kaki , di mana server dijamin identitas pengguna, dan otentikasi tiga-kaki , di mana server dijamin oleh penyedia konten identitas pengguna. Otentikasi tiga kaki adalah tempat permintaan otorisasi dan token akses ikut berperan, dan penting untuk dicatat bahwa OAuth 1 juga memilikinya.

Yang kompleks: otentikasi berkaki tiga

Poin utama dari spesifikasi OAuth adalah penyedia konten (mis. Facebook, Twitter, dll.) Untuk memastikan server (misalnya aplikasi Web yang ingin berbicara dengan penyedia konten atas nama klien) bahwa klien memiliki identitas . Apa yang ditawarkan otentikasi tiga kaki adalah kemampuan untuk melakukan hal itu tanpa perlu klien atau server mengetahui detail identitas itu (misalnya nama pengguna dan kata sandi).

Tanpa (?) Terlalu jauh ke detail OAuth:

1. Klien mengajukan permintaan otorisasi ke server, yang memvalidasi bahwa klien adalah klien sah dari layanannya.
2. Server mengalihkan klien ke penyedia konten untuk meminta akses ke sumber dayanya.
3. Penyedia konten memvalidasi identitas pengguna, dan sering meminta izin mereka untuk mengakses sumber daya.
4. Penyedia konten mengarahkan kembali klien ke server, memberitahukan keberhasilan atau kegagalan. Permintaan ini mencakup kode otorisasi tentang kesuksesan.
5. Server membuat permintaan out-of-band ke penyedia konten dan menukar kode otorisasi untuk token akses.

Server sekarang dapat membuat permintaan ke penyedia konten atas nama pengguna dengan melewati token akses.

Setiap pertukaran (klien-> server, server-> penyedia konten) mencakup validasi rahasia bersama, tetapi karena OAuth 1 dapat melewati koneksi yang tidak terenkripsi, setiap validasi tidak dapat melewati rahasia melalui kabel.

Itu dilakukan, seperti yang telah Anda catat, dengan HMAC. Klien menggunakan rahasia yang dibagikan dengan server untuk menandatangani argumen untuk permintaan otorisasi. Server mengambil argumen, menandatanganinya sendiri dengan kunci klien, dan dapat melihat apakah itu klien yang sah (dalam langkah 1 di atas).

Tanda tangan ini mengharuskan klien dan server untuk menyetujui urutan argumen (jadi mereka menandatangani string yang sama persis), dan salah satu keluhan utama tentang OAuth 1 adalah bahwa ia membutuhkan server dan klien untuk mengurutkan dan tanda tangan secara identik. Ini adalah kode fiddly dan itu benar atau Anda dapat 401 Unauthorizedsedikit bantuan. Ini meningkatkan penghalang untuk menulis klien.

Dengan meminta permintaan otorisasi untuk berjalan di atas SSL, OAuth 2.0 menghapus kebutuhan untuk menyortir dan menandatangani argumen secara bersamaan. Klien meneruskan rahasianya ke server, yang memvalidasinya secara langsung.

Persyaratan yang sama ada di server-> koneksi penyedia konten, dan karena itulah SSL yang menghilangkan satu penghalang untuk menulis server yang mengakses layanan OAuth.

Itu membuat banyak hal lebih mudah dalam langkah 1, 2, dan 5 di atas.

Jadi pada titik ini server kami memiliki token akses permanen yang setara dengan nama pengguna / kata sandi untuk pengguna. Itu dapat membuat permintaan ke penyedia konten atas nama pengguna dengan melewatkan token akses itu sebagai bagian dari permintaan (sebagai argumen kueri, header HTTP, atau data formulir POST).

Jika layanan konten diakses hanya melalui SSL, kami selesai. Jika tersedia melalui HTTP biasa, kami ingin melindungi token akses permanen itu dengan beberapa cara. Siapa pun yang mengendus koneksi akan bisa mendapatkan akses ke konten pengguna selamanya.

Cara yang diselesaikan di OAuth 2 adalah dengan token penyegaran . Token penyegaran menjadi setara kata sandi permanen, dan itu hanya pernah dikirimkan melalui SSL . Ketika server membutuhkan akses ke layanan konten, ia menukar token penyegaran dengan token akses yang berumur pendek. Dengan cara itu semua akses HTTP yang dapat diakses dibuat dengan token yang akan kedaluwarsa. Google menggunakan 5 menit kedaluwarsa pada OAuth 2 API mereka.

Jadi selain dari token penyegaran, OAuth 2 menyederhanakan semua komunikasi antara klien, server, dan penyedia konten. Dan token penyegaran hanya ada untuk memberikan keamanan saat konten sedang diakses tidak dienkripsi.

Otentikasi dua kaki

Namun, terkadang server hanya perlu mengontrol akses ke kontennya sendiri. Otentikasi dua kaki memungkinkan klien untuk mengotentikasi pengguna secara langsung dengan server.

OAuth 2 menstandarkan beberapa ekstensi ke OAuth 1 yang digunakan secara luas. Yang saya tahu paling baik diperkenalkan oleh Twitter sebagai xAuth . Anda dapat melihatnya di OAuth 2 sebagai Kredensial Kata Sandi Pemilik Sumber Daya .

Pada dasarnya, jika Anda dapat mempercayai klien dengan kredensial pengguna (nama pengguna dan kata sandi), mereka dapat bertukar secara langsung dengan penyedia konten untuk token akses. Ini membuat OAuth jauh lebih berguna pada aplikasi seluler - dengan otentikasi tiga kaki, Anda harus menyematkan tampilan HTTP untuk menangani proses otorisasi dengan server konten.

Dengan OAuth 1, ini bukan bagian dari standar resmi, dan mengharuskan prosedur penandatanganan yang sama dengan semua permintaan lainnya.

Saya baru saja mengimplementasikan sisi server OAuth 2 dengan Kredensial Kata Sandi Pemilik Sumber Daya, dan dari sudut pandang klien, mendapatkan token akses menjadi sederhana: meminta token akses dari server, meneruskan id / rahasia klien sebagai header Otorisasi HTTP dan login / kata sandi pengguna sebagai data formulir.

Keuntungan: Kesederhanaan

Jadi dari perspektif implementor, keuntungan utama yang saya lihat di OAuth 2 adalah berkurangnya kompleksitas. Itu tidak memerlukan prosedur penandatanganan permintaan, yang tidak sepenuhnya sulit tetapi tentu saja fiddly. Ini sangat mengurangi pekerjaan yang diperlukan untuk bertindak sebagai klien suatu layanan, yang mana (di dunia mobile modern) Anda paling ingin meminimalkan rasa sakit. Berkurangnya kompleksitas pada server-> penyedia konten membuatnya lebih terukur di pusat data.

Dan itu mengkodifikasikan ke dalam standar beberapa ekstensi untuk OAuth 1.0a (seperti xAuth) yang sekarang digunakan secara luas.

Pertama, sebagaimana ditunjukkan dengan jelas dalam otentikasi OAuth

OAuth 2.0 bukan protokol otentikasi.

Otentikasi dalam konteks pengguna yang mengakses aplikasi memberi tahu aplikasi siapa pengguna saat ini dan apakah mereka ada atau tidak. Protokol otentikasi lengkap mungkin juga akan memberi tahu Anda sejumlah atribut tentang pengguna ini, seperti pengidentifikasi unik, alamat email, dan apa yang harus memanggil mereka ketika aplikasi mengatakan "Selamat Pagi".

Namun, OAuth tidak memberitahukan aplikasi itu. OAuth sama sekali tidak mengatakan apa-apa tentang pengguna, juga tidak mengatakan bagaimana pengguna membuktikan keberadaan mereka atau bahkan jika mereka masih di sana. Sejauh menyangkut klien OAuth, ia meminta token, mendapat token, dan akhirnya menggunakan token itu untuk mengakses beberapa API. Tidak tahu apa-apa tentang siapa yang mengotorisasi aplikasi atau apakah ada pengguna sama sekali.

Ada standar untuk otentikasi pengguna menggunakan OAuth: OpenID Connect, kompatibel dengan OAuth2.

OpenID Connect ID Token adalah JSON Web Token (JWT) yang ditandatangani yang diberikan kepada aplikasi klien di samping token akses OAuth biasa. ID Token berisi serangkaian klaim tentang sesi otentikasi, termasuk pengidentifikasi untuk pengguna (sub), pengidentifikasi untuk penyedia identitas yang mengeluarkan token (iss), dan pengidentifikasi klien yang membuat token ini dibuat ( aud).

Di Go, Anda dapat melihat coreos / dex, sebuah OpenID Connect Identity (OIDC) dan Penyedia OAuth 2.0 dengan Konektor Pluggable.

Jawab dari postingan ini vonc

Saya akan menjawab pertanyaan ini sedikit berbeda, dan saya akan sangat tepat dan singkat, terutama karena @Peter T menjawab semuanya.

Keuntungan utama yang saya lihat dari standar ini adalah untuk menghormati dua prinsip:

1. Pemisahan masalah.
2. Otentikasi decoupling dari aplikasi web, yang biasanya melayani bisnis.

Dengan melakukan itu,

1. Anda dapat menerapkan alternatif untuk Single SignOn: Jika Anda memiliki beberapa aplikasi yang mempercayai satu STS. Yang saya maksud, satu nama pengguna untuk semua aplikasi.
2. Anda dapat mengaktifkan aplikasi web Anda (Klien) untuk mengakses sumber daya milik pengguna dan bukan milik aplikasi web (Klien).
3. Anda dapat mengamanatkan proses otentikasi kepada pihak ketiga yang Anda percayai, dan tidak pernah khawatir tentang validasi keaslian pengguna.