Bagaimana OAuth 2 melindungi terhadap hal-hal seperti serangan replay menggunakan Token Keamanan?

Seperti yang saya pahami, rantai peristiwa berikut ini terjadi di OAuth 2 untuk Site-Amengakses informasi PenggunaSite-B .

1. Site-Amendaftar Site-B, dan mendapatkan Rahasia dan ID.
2. Ketika Pengguna mengatakan Site-Auntuk mengakses Site-B, Pengguna dikirim ke Site-Btempat mereka mengatakan Site-Bbahwa mereka memang ingin memberikan Site-Aizin ke informasi tertentu.
3. Site-Bmengalihkan pengguna kembali ke Site-A, bersama dengan Kode Otorisasi.
4. Site-Akemudian meneruskan Kode Otorisasi tersebut bersama dengan Rahasia kembali Site-Bsebagai imbalan untuk Token Keamanan.
5. Site-Akemudian membuat permintaan Site-Batas nama Pengguna dengan menggabungkan Token Keamanan bersama dengan permintaan.

Bagaimana semua ini bekerja dalam hal keamanan dan enkripsi, pada level tinggi? Bagaimana OAuth 2 melindungi terhadap hal-hal seperti serangan replay menggunakan Token Keamanan?

Bagaimana OAuth 2.0 bekerja di kehidupan nyata:

Saya sedang mengemudi oleh toko roti Olaf dalam perjalanan ke tempat kerja ketika saya melihat donat paling enak di jendela - maksud saya, benda itu meneteskan kebaikan cokelat. Jadi saya masuk ke dalam dan menuntut "Saya harus punya donat itu!". Dia berkata "yakin itu akan menjadi $ 30."

Ya saya tahu, $ 30 untuk satu donat! Pasti enak! Saya meraih dompet saya ketika tiba-tiba saya mendengar koki berteriak "TIDAK! Tidak ada donat untuk Anda". Saya bertanya: mengapa? Dia bilang dia hanya menerima transfer bank.

Serius? Ya, dia serius. Saya hampir berjalan di sana, tetapi kemudian donat memanggil saya: "Makan saya, saya enak ...". Siapa saya untuk tidak mematuhi perintah dari donat? Saya bilang ok.

Dia memberi saya sebuah catatan dengan namanya (koki, bukan donat): "Katakan pada mereka, Olaf mengirimimu" Namanya sudah ada di catatan, jadi saya tidak tahu apa maksud dari mengatakan itu, tapi ok.

Saya berkendara satu setengah jam ke bank saya. Saya menyerahkan catatan itu ke kasir; Saya mengatakan kepadanya bahwa Olaf mengirimi saya. Dia memberi saya salah satu dari penampilan itu, jenis yang mengatakan, "Saya bisa membaca".

Dia mengambil catatan saya, menanyakan id saya, menanyakan berapa banyak uang yang boleh diberikan kepadanya. Saya memberi tahu dia $ 30 dolar. Dia menulis dan memberi saya catatan lain. Yang ini memiliki banyak angka, saya kira itulah cara mereka melacak catatan.

Pada saat itu saya kelaparan. Saya bergegas keluar dari sana, satu setengah jam kemudian saya kembali, berdiri di depan Olaf dengan catatan saya diperpanjang. Dia mengambilnya, memeriksanya dan berkata, "Aku akan kembali".

Saya pikir dia mendapatkan donat saya, tetapi setelah 30 menit saya mulai curiga. Jadi saya bertanya kepada orang di belakang konter "Di mana Olaf?". Dia berkata "Dia pergi untuk mendapatkan uang". "Apa maksudmu?". "Dia mencatat ke bank".

Hah ... jadi Olaf mencatat bahwa bank memberi saya dan kembali ke bank untuk mendapatkan uang dari rekening saya. Karena dia memiliki catatan yang diberikan bank kepada saya, bank tahu dia adalah orang yang saya bicarakan, dan karena saya berbicara dengan bank, mereka tahu hanya memberinya $ 30.

Butuh waktu lama bagi saya untuk mengetahuinya karena pada saat saya melihat ke atas, Olaf berdiri di depan saya akhirnya menyerahkan donat saya. Sebelum saya pergi saya harus bertanya, "Olaf, apakah Anda selalu menjual donat dengan cara ini?". "Tidak, aku dulu melakukannya dengan berbeda."

Hah. Ketika saya berjalan kembali ke mobil, telepon saya berdering. Aku tidak repot-repot menjawab, mungkin tugasku memanggilku untuk memecatku, bosku memang pelacur. Selain itu, saya terjebak memikirkan proses yang baru saja saya lalui.

Maksud saya pikirkan: Saya bisa membiarkan Olaf mengambil $ 30 dari rekening bank saya tanpa harus memberinya informasi akun saya. Dan saya tidak perlu khawatir dia akan mengeluarkan terlalu banyak uang karena saya sudah memberi tahu bank bahwa dia hanya diperbolehkan mengambil $ 30. Dan bank tahu dia adalah orang yang tepat karena dia memiliki catatan yang mereka berikan kepada saya untuk diberikan kepada Olaf.

Ok, tentu saja saya lebih suka menyerahkan $ 30 dari saku saya. Tetapi sekarang setelah dia memiliki catatan itu, saya hanya bisa memberi tahu bank untuk membiarkannya menerima $ 30 setiap minggu, lalu saya bisa muncul di toko roti dan saya tidak harus pergi ke bank lagi. Saya bahkan bisa memesan donat melalui telepon jika saya mau.

Tentu saja saya tidak akan pernah melakukan itu - donat itu menjijikkan.

Saya ingin tahu apakah pendekatan ini memiliki aplikasi yang lebih luas. Dia menyebutkan ini adalah pendekatan keduanya, saya bisa menyebutnya Olaf 2.0. Pokoknya saya lebih baik pulang, saya harus mulai mencari pekerjaan baru. Tetapi tidak sebelum saya mendapatkan salah satu dari getah stroberi dari tempat baru di seberang kota, saya perlu sesuatu untuk menghilangkan rasa donat itu.

Berdasarkan apa yang saya baca, ini adalah cara kerjanya:

Alur umum yang diuraikan dalam pertanyaan itu benar. Pada langkah 2, Pengguna X diautentikasi, dan juga mengotorisasi akses Situs A ke informasi Pengguna X di Situs B. Pada langkah 4, situs meneruskan Rahasia kembali ke Situs B, mengotentikasi dirinya sendiri, serta Kode Otorisasi, yang menunjukkan apa itu meminta (token akses Pengguna X).

Secara keseluruhan, OAuth 2 sebenarnya adalah model keamanan yang sangat sederhana, dan enkripsi tidak pernah langsung berperan. Alih-alih, Rahasia dan Token Keamanan pada dasarnya adalah kata sandi, dan semuanya dijamin hanya oleh keamanan koneksi https.

OAuth 2 tidak memiliki perlindungan terhadap serangan replay dari Token Keamanan atau Rahasia. Sebaliknya, ini sepenuhnya bergantung pada Situs B yang bertanggung jawab dengan barang-barang ini dan tidak membiarkannya keluar, dan pada mereka dikirim melalui https saat dalam perjalanan (https akan melindungi parameter URL).

Tujuan dari langkah Kode Otorisasi hanyalah kenyamanan, dan Kode Otorisasi tidak terlalu sensitif sendiri. Ini memberikan pengidentifikasi umum untuk token akses Pengguna X untuk Situs A ketika meminta Situs B untuk token akses Pengguna X. Id pengguna Just X di Situs B tidak akan bekerja, karena mungkin ada banyak token akses luar biasa yang menunggu untuk dibagikan ke situs yang berbeda pada saat yang sama.

OAuth adalah protokol di mana aplikasi 3-pihak dapat mengakses data Anda yang disimpan di situs web lain tanpa akun dan kata sandi Anda. Untuk definisi yang lebih resmi, lihat Wiki atau spesifikasi.

Berikut ini adalah demo use case:

1. Saya masuk ke LinkedIn dan ingin menghubungkan beberapa teman yang ada di kontak Gmail saya. LinkedIn mendukung ini. Ini akan meminta sumber daya yang aman (daftar kontak gmail saya) dari gmail. Jadi saya klik tombol ini:
   

2. Halaman web muncul, dan itu menunjukkan halaman login Gmail, ketika saya memasukkan akun dan kata sandi saya:
   

3. Gmail kemudian menampilkan halaman persetujuan tempat saya mengklik "Terima":

4. Sekarang LinkedIn dapat mengakses kontak saya di Gmail:

Di bawah ini adalah diagram alur dari contoh di atas:

Langkah 1: LinkedIn meminta token dari Server Otorisasi Gmail.

Langkah 2: Server otorisasi Gmail mengautentikasi pemilik sumber daya dan menunjukkan kepada pengguna halaman persetujuan. (pengguna harus masuk ke Gmail jika mereka belum masuk)

Langkah 3: Pengguna mengabulkan permintaan LinkedIn untuk mengakses data Gmail.

Langkah 4: server otorisasi Gmail merespons kembali dengan token akses.

Langkah 5: LinkedIn memanggil API Gmail dengan token akses ini.

Langkah 6: Server sumber daya Gmail mengembalikan kontak Anda jika token akses valid. (Token akan diverifikasi oleh server sumber daya Gmail)

Anda bisa mendapatkan lebih banyak dari detail tentang OAuth di sini .

Gambar 1, diangkat dari RFC6750 :

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

Beginilah cara Oauth 2.0 bekerja, dijelaskan dengan baik di artikel ini

Ini adalah permata:

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

Ringkasan yang sangat singkat:

OAuth mendefinisikan empat peran:

1. Pemilik Sumberdaya
2. Klien
3. Server Sumber Daya
4. Server Otorisasi

Anda (Pemilik Sumber Daya) memiliki ponsel. Anda memiliki beberapa akun email berbeda, tetapi Anda ingin semua akun email Anda dalam satu aplikasi, jadi Anda tidak perlu terus berpindah. Jadi GMail Anda (Klien) meminta akses (melalui Server Otorisasi Yahoo) ke email Yahoo Anda (Server Sumber Daya) sehingga Anda dapat membaca kedua email itu pada aplikasi GMail Anda.

Alasan OAuth ada adalah karena GMail tidak aman untuk menyimpan nama pengguna dan kata sandi Yahoo Anda.

Jawaban lainnya sangat terperinci dan menjawab sebagian besar pertanyaan yang diajukan oleh OP.

Untuk menguraikan, dan secara khusus untuk menjawab pertanyaan OP tentang "Bagaimana OAuth 2 melindungi terhadap hal-hal seperti serangan replay menggunakan Token Keamanan?", Ada dua perlindungan tambahan dalam rekomendasi resmi untuk menerapkan OAuth 2:

1) Token biasanya akan memiliki periode kedaluwarsa singkat ( http://tools.ietf.org/html/rfc6819#section-5.1.5.3 ):

Waktu kedaluwarsa singkat untuk token adalah cara perlindungan terhadap ancaman berikut:

• ulangan...

2) Ketika token digunakan oleh Situs A, rekomendasi adalah bahwa token itu akan disajikan bukan sebagai parameter URL tetapi di bidang header permintaan Otorisasi ( http://tools.ietf.org/html/rfc6750 ):

Klien HARUS membuat permintaan terotentikasi dengan token pembawa menggunakan bidang header permintaan "Otorisasi" dengan skema otorisasi HTTP "Pembawa". ...

Metode "application / x-www-form-urlencoded" TIDAK HARUS digunakan kecuali dalam konteks aplikasi di mana browser yang berpartisipasi tidak memiliki akses ke bidang header permintaan "Otorisasi". ...

Parameter Kueri URI ... disertakan untuk mendokumentasikan penggunaan saat ini; penggunaannya tidak disarankan, karena defisiensi keamanannya

Berikut ini mungkin penjelasan paling sederhana tentang cara kerja OAuth2 untuk semua 4 jenis hibah, yaitu, 4 aliran berbeda di mana aplikasi dapat memperoleh token akses.

Kesamaan

Semua aliran jenis hibah memiliki 2 bagian:

• Dapatkan token akses
• Gunakan token akses

Bagian ke-2 'gunakan token akses' adalah sama untuk semua aliran

Perbedaan

Bagian pertama dari aliran 'dapatkan token akses' untuk setiap jenis hibah bervariasi.

Namun, secara umum bagian 'dapatkan akses token' dapat diringkas sebagai terdiri dari 5 langkah:

1. Pra-daftarkan aplikasi Anda (klien) dengan penyedia OAuth, misalnya, Twitter, dll. Untuk mendapatkan id / rahasia klien
2. Buat tombol login sosial dengan id klien & lingkup / izin yang diperlukan pada halaman Anda sehingga ketika pengguna yang diklik akan dialihkan ke penyedia OAuth untuk diautentikasi
3. Penyedia OAuth meminta pengguna untuk memberikan izin ke aplikasi Anda (klien)
4. Penyedia OAuth mengeluarkan kode
5. Aplikasi (klien) memperoleh token akses

Berikut ini adalah diagram berdampingan yang membandingkan bagaimana setiap aliran jenis hibah berbeda berdasarkan 5 langkah.

Diagram ini dari https://blog.oauth.io/introduction-oauth2-flow-diagrams/

Masing-masing memiliki tingkat kesulitan implementasi, keamanan, dan kasus yang berbeda. Tergantung pada kebutuhan dan situasi Anda, Anda harus menggunakan salah satunya. Yang mana untuk digunakan?

Kredensial Klien : Jika aplikasi Anda hanya melayani satu pengguna

Kata sandi pemilik sumber daya Crendential : Ini harus digunakan hanya sebagai pilihan terakhir karena pengguna harus menyerahkan kredensial ke aplikasi, yang berarti aplikasi dapat melakukan semua yang dapat dilakukan pengguna

Kode Otorisasi : Cara terbaik untuk mendapatkan otorisasi pengguna

Tersirat : Jika aplikasi Anda adalah aplikasi seluler atau satu halaman

Ada penjelasan lebih lanjut tentang pilihan di sini: https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/