Geekly articles weekly

Mobile OAuth 2.0 Security



Halo semuanya! Saya Nikita Stupin, Spesialis Keamanan Informasi, Mail.Ru Mail. Belum lama ini, saya melakukan penelitian kerentanan pada ponsel OAuth 2.0. Untuk membuat skema OAuth 2.0 seluler yang aman, tidak cukup menerapkan standar dalam bentuk murni dan memeriksa redirect_uri. Penting untuk mempertimbangkan spesifikasi aplikasi seluler dan menerapkan mekanisme perlindungan tambahan.

Pada artikel ini saya ingin berbagi dengan Anda pengetahuan tentang serangan pada ponsel OAuth 2.0, tentang metode perlindungan dan implementasi aman dari protokol ini. Semua komponen perlindungan yang diperlukan, yang akan saya bahas di bawah, diimplementasikan di SDK terbaru untuk klien seluler Mail.Ru Mail.

Sifat dan fungsi OAuth 2.0


OAuth 2.0 adalah protokol otorisasi yang menjelaskan bagaimana aman bagi layanan klien untuk mengakses sumber daya pengguna pada penyedia layanan. Pada saat yang sama, OAuth 2.0 menyelamatkan pengguna dari keharusan memasukkan kata sandi di luar penyedia layanan: seluruh proses dikurangi menjadi mengklik tombol "Saya setuju untuk memberikan akses ke ...".

Penyedia dalam hal OAuth 2.0 adalah layanan yang memiliki data pengguna dan, dengan izin pengguna, menyediakan layanan pihak ketiga (klien) dengan akses yang aman ke data ini. Klien adalah aplikasi yang ingin menerima data pengguna dari penyedia.

Beberapa waktu setelah rilis protokol OAuth 2.0, pengembang biasa mengadaptasinya untuk otentikasi, meskipun awalnya tidak dimaksudkan untuk ini. Otentikasi menggeser vektor serangan dari data pengguna yang disimpan di penyedia layanan ke akun pengguna layanan pengguna.

Itu tidak terbatas pada otentikasi saja. Di era aplikasi seluler dan peninggian konversi, memasuki aplikasi dengan satu tombol menjadi sangat menggoda. Pengembang menempatkan OAuth 2.0 di rel seluler. Secara alami, sedikit orang yang memikirkan keamanan dan spesifikasi aplikasi seluler: sekali dan lagi, dan dalam produksi. Namun, OAuth 2.0 umumnya tidak berfungsi dengan baik di luar aplikasi web: masalah yang sama diamati di kedua aplikasi seluler dan desktop.

Mari kita cari tahu cara membuat OAuth 2.0 mobile yang aman.

Bagaimana cara kerjanya?


Ingat bahwa pada perangkat seluler, klien mungkin bukan peramban, tetapi aplikasi seluler tanpa backend. Karena itu, kami dihadapkan pada dua masalah keamanan utama untuk seluler OAuth 2.0:

  1. Klien tidak dipercaya.
  2. Perilaku pengalihan dari browser ke aplikasi seluler tergantung pada pengaturan dan aplikasi yang telah diinstal pengguna.

Aplikasi seluler adalah klien publik


Untuk memahami akar masalah pertama, mari kita lihat bagaimana OAuth 2.0 bekerja jika terjadi interaksi server-ke-server, dan kemudian membandingkannya dengan OAuth 2.0 jika terjadi interaksi klien-ke-server.

Dalam kedua kasus, semuanya dimulai dengan fakta bahwa klien layanan mendaftar dengan penyedia layanan dan menerima client_id dan, dalam beberapa kasus, client_secret . Nilai client_id bersifat publik dan diperlukan untuk mengidentifikasi layanan klien, tidak seperti client_secret , yang nilainya bersifat pribadi. Proses pendaftaran dijelaskan secara lebih rinci dalam RFC 7591 .

Diagram di bawah ini menunjukkan operasi OAuth 2.0 dalam komunikasi server-ke-server.


Gambar diambil dari https://tools.ietf.org/html/rfc6749#section-1.2

Ada 3 tahapan utama protokol OAuth 2.0:

  1. [Langkah-langkah AC] Dapatkan Kode Otorisasi (selanjutnya hanya code ).
  2. [Langkah DE] code pertukaran untuk access_token .
  3. Akses sumber daya menggunakan access_token .

Mari kita periksa penerimaan kode secara lebih rinci:

  1. [Langkah A] Klien layanan mengarahkan pengguna ke penyedia layanan.
  2. [Langkah B] Penyedia layanan meminta izin dari pengguna untuk memberikan data ke layanan klien (panah B ke atas). Pengguna menyediakan akses ke data (panah B ke kanan).
  3. [Langkah C] Penyedia layanan mengembalikan code ke browser pengguna, yang mengarahkan ulang code layanan klien.

Mari kita access_token mendapatkan access_token lebih rinci:

  1. [Langkah D] Server klien mengirimkan permintaan untuk access_token . Permintaan tersebut meliputi: code , client_secret dan redirect_uri .
  2. [Langkah E] Dalam hal code valid, client_secret dan redirect_uri , client_secret disediakan.

Permintaan untuk access_token dilakukan sesuai dengan skema server-ke-server, oleh karena itu, secara umum, untuk mencuri client_secret penyerang harus meretas server-klien-server atau server penyedia layanan.

Sekarang mari kita lihat seperti apa skema OAuth 2.0 pada perangkat seluler tanpa backend (interaksi klien-ke-server).


Gambar diambil dari https://tools.ietf.org/html/rfc8252#section-4.1

Skema umum dibagi menjadi 3 langkah utama yang sama:

  1. [langkah 1-4 dalam gambar] Dapatkan code .
  2. [langkah 5-6 dalam gambar] code pertukaran untuk access_token .
  3. Akses sumber daya menggunakan access_token .

Namun, dalam hal ini, aplikasi seluler juga bertindak sebagai server, yang berarti client_secret akan client_secret ke dalam aplikasi. Ini mengarah pada fakta bahwa pada perangkat seluler tidak mungkin menyimpan rahasia lient_secret dari penyerang. client_secret dua cara untuk mendapatkan client_secret ke dalam aplikasi: untuk menyaring lalu lintas dari aplikasi ke server atau merekayasa balik aplikasi. Kedua metode ini mudah diterapkan, sehingga client_secret berguna di perangkat seluler.

Mengenai skema client-to-server, Anda mungkin memiliki pertanyaan: "mengapa tidak segera mendapatkan access_token ?". Kelihatannya, mengapa kita perlu langkah ekstra? Selain itu, ada skema Hibah Implisit di mana klien segera menerima access_token . Meskipun dapat digunakan dalam beberapa kasus, kita akan melihat di bawah ini bahwa Implisit Grant tidak cocok untuk OAuth 2.0 seluler yang aman.

Redirect di perangkat seluler


Secara umum, untuk pengalihan dari browser ke aplikasi pada perangkat seluler, skema URI Khusus dan mekanisme AppLink digunakan. Tidak satu pun dari mekanisme ini dalam bentuk murni yang dapat diandalkan seperti pengalihan browser.

Skema URI khusus (atau tautan dalam) digunakan sebagai berikut: pengembang menentukan skema aplikasi sebelum perakitan. Skema dapat arbitrer, sementara pada perangkat yang sama beberapa aplikasi dengan skema yang sama dapat diinstal. Semuanya cukup sederhana ketika setiap aplikasi pada perangkat sesuai dengan satu aplikasi. Tetapi bagaimana jika dua aplikasi mendaftarkan sirkuit yang sama pada perangkat yang sama? Bagaimana sistem operasi menentukan mana dari dua aplikasi yang akan dibuka ketika mengakses Skema URI Khusus? Android akan menampilkan jendela dengan pilihan aplikasi tempat Anda ingin membuka tautan. Di iOS, perilaku tidak didefinisikan , yang berarti bahwa salah satu dari kedua aplikasi dapat dibuka. Dalam kedua kasus, penyerang dapat mencegat kode atau access_token .

AppLink, berbeda dengan Skema URI Khusus, dijamin untuk membuka aplikasi yang tepat, tetapi mekanisme ini memiliki beberapa kelemahan:

  1. Setiap klien layanan harus secara independen melewati prosedur verifikasi .
  2. Pengguna Android dapat mematikan AppLink untuk aplikasi tertentu di pengaturan.
  3. Android di bawah 6.0 dan iOS di bawah 9.0 tidak mendukung AppLink.

Kerugian AppLink di atas, pertama, meningkatkan ambang entri untuk layanan klien potensial, dan kedua, dapat mengarah pada fakta bahwa dalam keadaan tertentu pengguna tidak akan bekerja OAuth 2.0. Ini membuat AppLink tidak cocok untuk mengganti pengalihan browser dalam protokol OAuth 2.0.

Oke, apa yang harus diserang?


Masalah ponsel OAuth 2.0 juga memunculkan serangan spesifik. Mari kita lihat siapa mereka dan bagaimana mereka bekerja.

Serangan Intersepsi Kode Otorisasi


Data awal: aplikasi yang sah (klien OAuth 2.0) dan aplikasi jahat yang mendaftarkan skema yang sama dengan yang sah diinstal pada perangkat pengguna. Gambar di bawah ini menunjukkan skema serangan.


Gambar diambil dari https://tools.ietf.org/html/rfc7636#section-1

Inilah masalahnya: pada langkah 4, browser mengembalikan code ke aplikasi melalui Skema URI Kustom, sehingga code dapat dicegat oleh malware (karena terdaftar skema yang sama dengan aplikasi yang sah). Setelah itu, malware mengubah code menjadi access_token dan mendapatkan akses ke data pengguna.

Bagaimana cara melindungi diri sendiri? Dalam beberapa kasus, mekanisme komunikasi antarproses dapat digunakan, kita akan membicarakannya di bawah ini. Dalam kasus umum, Anda perlu menerapkan skema yang disebut Kunci Bukti untuk Pertukaran Kode . Esensinya tercermin dalam diagram di bawah ini.


Gambar diambil dari https://tools.ietf.org/html/rfc7636#section-1.1

Dalam permintaan dari klien, ada beberapa parameter tambahan: code_verifier , code_challenge (pada t(code_verifier) ) dan code_challenge_method (pada diagram t_m ).

Code_verifier adalah angka acak dengan panjang setidaknya 256 bit yang hanya digunakan sekali . Artinya, untuk setiap permintaan code klien harus membuat code_verifier baru.

Code_challenge_method adalah nama fungsi konversi, paling sering SHA-256.

Code_challenge adalah code_verifier yang konversi code_challenge_method telah code_challenge_method dan dikodekan dalam URL Safe Base64.

Konversi code_verifier ke code_challenge diperlukan untuk melindungi terhadap serangan vektor berdasarkan intersepsi code_verifier (misalnya, dari log sistem perangkat) ketika meminta code .

Jika perangkat pengguna tidak mendukung SHA-256, maka penurunan versi diizinkan hingga konversi code_verifier hilang . Dalam semua kasus lain, Anda harus menggunakan SHA-256.

Skema ini bekerja sebagai berikut:

  1. Klien menghasilkan code_verifier dan mengingatnya.
  2. Klien memilih code_challenge_method dan mendapatkan code_challenge dari code_verifier .
  3. [Langkah A] Klien meminta code , dengan code_challenge dan code_challenge_method ditambahkan ke permintaan.
  4. [Langkah B] Penyedia mengingat code_challenge dan code_challenge_method di server dan mengembalikan code klien.
  5. [Langkah C] Klien meminta access_token , dengan access_token ditambahkan ke code_verifier .
  6. Penyedia menerima code_challenge dari code_challenge yang masuk, dan kemudian memeriksanya terhadap code_challenge , yang ia ingat.
  7. [Langkah D] Jika nilainya cocok, penyedia akan mengeluarkan access_token klien.

Mari kita code_challenge mengapa code_challenge memungkinkan code_challenge melindungi diri dari serangan intersepsi kode. Untuk melakukan ini, kita akan melalui tahapan mendapatkan access_token .

  1. Pertama, code permintaan aplikasi yang sah ( code_challenge dan code_challenge_method dikirim bersama dengan permintaan ).
  2. Malware memotong code (tetapi bukan code_challenge , karena tidak ada code_challenge dalam respons ).
  3. Malware meminta access_token (dengan code valid, tetapi tanpa code_verifier valid).
  4. Server memperhatikan ketidakcocokan code_challenge dan melemparkan kesalahan.

Perhatikan bahwa penyerang tidak memiliki kemampuan untuk menebak code_verifier (256 bit acak!) Atau menemukannya di suatu tempat di log ( code_verifier ditransmisikan sekali).

Jika semua ini direduksi menjadi satu frasa, maka code_challenge memungkinkan penyedia layanan menjawab pertanyaan: "apakah access_token diminta oleh aplikasi klien yang sama yang meminta code , atau oleh yang lain?"

OAuth 2.0 CSRF


Pada perangkat seluler, OAuth 2.0 sering digunakan sebagai mekanisme otentikasi. Seperti yang kita ingat, otentikasi melalui OAuth 2.0 berbeda dari otorisasi dalam hal kerentanan OAuth 2.0 memengaruhi data pengguna di sisi klien layanan, dan bukan penyedia layanan. Akibatnya, serangan CSRF pada OAuth 2.0 memungkinkan Anda untuk mencuri akun orang lain.

Pertimbangkan serangan CSRF terhadap OAuth 2.0 menggunakan contoh aplikasi klien taksi dan penyedia provider.com. Pertama, seorang penyerang masuk ke attacker@provider.com di perangkatnya dan menerima code untuk taksi. Setelah itu, penyerang menyela proses OAuth 2.0 dan menghasilkan tautan:

com.taxi.app://oauth?
code=b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4

Kemudian penyerang mengirimkan tautan ke korban, misalnya, dengan kedok surat atau SMS dari administrasi taksi. Korban access_token tautan, aplikasi taksi terbuka di teleponnya, yang menerima access_token , dan sebagai akibatnya korban berakhir di akun taksi penyerang . Tidak menyadari tangkapannya, korban menggunakan akun ini: melakukan perjalanan, memasukkan datanya, dll.

Sekarang, penyerang dapat masuk ke akun taksi korban kapan saja karena ia terikat dengan attacker@provider.com . Serangan CSRF saat masuk diizinkan mencuri akun.

Serangan CSRF biasanya dilindungi dengan token CSRF (juga disebut state ), dan OAuth 2.0 tidak terkecuali. Cara menggunakan token CSRF:

  1. Aplikasi klien menghasilkan dan menyimpan token CSRF di perangkat seluler pengguna.
  2. Aplikasi klien menyertakan token CSRF dalam permintaan code .
  3. Server mengembalikan token CSRF yang sama dalam respons bersama dengan kode.
  4. Aplikasi klien membandingkan token CSRF yang masuk dan disimpan. Jika nilainya cocok, maka prosesnya berlanjut.

Persyaratan token CSRF: panjang setidaknya 256 bit, diperoleh dari sumber sekuens pseudorandom yang baik.

Singkatnya, token CSRF memungkinkan aplikasi klien untuk menjawab pertanyaan: "apakah saya mulai mendapatkan access_token , atau ada seseorang yang mencoba menipu saya?"

Malware berpura-pura menjadi klien yang sah


Beberapa malware dapat meniru aplikasi yang sah dan menaikkan layar izin atas nama mereka (layar persetujuan adalah layar tempat pengguna melihat: "Saya setuju untuk memberikan akses ke ..."). Pengguna yang lalai dapat mengklik "izinkan", dan sebagai hasilnya, malware memperoleh akses ke data pengguna.

Android dan iOS menyediakan mekanisme untuk saling verifikasi aplikasi. Aplikasi penyedia dapat memverifikasi keabsahan aplikasi klien, dan sebaliknya.

Sayangnya, jika mekanisme OAuth 2.0 menggunakan aliran melalui browser, maka Anda tidak dapat bertahan melawan serangan ini.

Serangan lainnya


Kami memeriksa serangan yang unik untuk ponsel OAuth 2.0. Namun, jangan lupa tentang serangan pada OAuth 2.0 biasa: spoofing redirect_uri , intersepsi lalu lintas melalui koneksi yang tidak aman, dll. Anda dapat membaca lebih lanjut tentang mereka di sini .

Apa yang harus dilakukan


Kami mempelajari cara kerja protokol OAuth 2.0, dan mengetahui kerentanan apa yang ada dalam implementasi protokol ini pada perangkat seluler. Sekarang mari kita kumpulkan skema OAuth 2.0 seluler yang aman dari setiap bagian.

Bagus, buruk OAuth 2.0


Mari kita mulai dengan cara menaikkan layar izin dengan benar. Pada perangkat seluler, ada dua cara untuk membuka halaman web dari aplikasi asli (contoh aplikasi asli: Mail.Ru Mail, VK, Facebook).



Metode pertama disebut Tab Kustom Peramban (pada gambar di sebelah kiri). Catatan : Tab Khusus Peramban di Android disebut Tab Kustom Chrome, dan di iOS SafariViewController. Sebenarnya, ini adalah tab browser normal, yang ditampilkan langsung di aplikasi, mis. Tidak ada peralihan visual antar aplikasi.

Metode kedua disebut "meningkatkan WebView" (dalam gambar di sebelah kanan), dalam kaitannya dengan ponsel OAuth 2.0, saya menganggapnya buruk.

WebView adalah browser mandiri untuk aplikasi asli.

" Browser yang berdiri sendiri" berarti bahwa WebView tidak memungkinkan akses ke cookie, penyimpanan, cache, riwayat, dan data lainnya dari Safari dan browser Chrome. Kebalikannya juga benar: Safari dan Chrome tidak dapat mengakses data WebView.

“ Browser untuk aplikasi asli ” berarti bahwa aplikasi asli yang meningkatkan WebView memiliki akses penuh ke cookie, penyimpanan, cache, riwayat, dan data WebView lainnya.

Sekarang bayangkan: pengguna menekan tombol "log in using ..." dan WebView dari aplikasi jahat meminta nama pengguna dan kata sandi dari penyedia layanan.

Kegagalan sekaligus di semua lini:

  1. Pengguna memasukkan nama pengguna dan kata sandi dari akun penyedia layanan dalam aplikasi, yang dapat dengan mudah mencuri data ini.
  2. OAuth 2.0 pada awalnya dikembangkan agar tidak memasukkan nama pengguna dan kata sandi dari penyedia layanan.
  3. Pengguna terbiasa memasukkan login dan kata sandi di mana saja, kemungkinan phishing meningkat.

Karena semua argumen bertentangan dengan WebView, kesimpulannya menunjukkan dirinya sendiri: naikkan Tab Kustom Peramban untuk layar persetujuan.

Jika ada di antara Anda yang mendebat WebView alih-alih Tab Kustom Peramban, tuliskan di komentar, saya akan sangat berterima kasih.

Skema OAuth 2.0 Mobile Aman


Kami akan menggunakan skema Pemberian Kode Otorisasi karena memungkinkan kami untuk menambahkan code_challenge dan melindungi code_challenge dari serangan intersepsi kode.


Gambar diambil dari https://tools.ietf.org/html/rfc8252#section-4.1

Permintaan kode (langkah 1-2) akan terlihat seperti ini:

https://o2.mail.ru/code?
redirect_uri=com.mail.cloud.app%3A%2F%2Foauth&
anti_csrf=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24& code_challenge=ZjYxNzQ4ZjI4YjdkNWRmZjg4MWQ1N2FkZjQzNGVkODE1YTRhNjViNjJjMGY5MGJjNzdiOGEzMDU2ZjE3NGFiYw%3D%3D&
code_challenge_method=S256&
scope=email%2Cid&
response_type=code&
client_id=984a644ec3b56d32b0404777e1eb73390c

Pada langkah 3, browser menerima respons yang diarahkan:

com.mail.cloud.app://outh?
code=b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4&
anti_csrf=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24

Pada langkah 4, browser membuka Skema URI Kustom dan meneruskan code dan token CSRF ke aplikasi klien.

Permintaan untuk access_token (langkah 5):

https://o2.mail.ru/token?
code_verifier=e61748f28b7d5daf881d571df434ed815a4a65b62c0f90bc77b8a3056f174abc&
code=b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4&
client_id=984a644ec3b56d32b0404777e1eb73390c

Langkah terakhir mengembalikan respons dengan access_token .

Secara umum, skema di atas aman, tetapi ada juga kasus khusus di mana OAuth 2.0 dapat dibuat lebih sederhana dan sedikit lebih aman.

Android IPC


Android memiliki mekanisme pertukaran data dua arah antar proses: IPC (komunikasi antar proses). IPC lebih disukai daripada Skema URI Khusus karena dua alasan:

  1. Aplikasi yang membuka saluran IPC dapat memverifikasi keaslian aplikasi yang dibuka oleh sertifikatnya. Kebalikannya juga benar: aplikasi yang terbuka dapat memverifikasi keaslian aplikasi yang membukanya.
  2. Dengan mengirim permintaan melalui saluran IPC, pengirim dapat menerima respons melalui saluran yang sama. Bersama dengan verifikasi timbal balik (butir 1), ini berarti bahwa tidak ada proses pihak ketiga yang dapat mencegat access_token .



Dengan demikian, kita dapat menggunakan Hibah Implisit dan sangat menyederhanakan skema seluler OAuth 2.0. Tidak ada token code_challenge dan CSRF. Selain itu, kami akan dapat melindungi diri dari malware yang meniru klien yang sah untuk mencuri akun pengguna.

SDK pelanggan


Selain menerapkan skema keamanan seluler OAuth 2.0 yang dijelaskan di atas, penyedia layanan harus mengembangkan SDK untuk pelanggannya. Ini akan memfasilitasi implementasi OAuth 2.0 di sisi klien dan pada saat yang sama mengurangi jumlah kesalahan dan kerentanan.

Buat kesimpulan


Untuk penyedia OAuth 2.0, saya menyusun "Daftar Periksa Secure Mobile OAuth 2.0":

  1. Dasar yang kuat sangat penting. Dalam hal mobile OAuth 2.0, yayasan adalah skema atau protokol yang kami pilih untuk diterapkan. Saat menerapkan skema OAuth 2.0 Anda sendiri, mudah untuk membuat kesalahan. Yang lain sudah mengisi gundukan dan membuat kesimpulan, tidak ada yang salah dengan belajar dari kesalahan mereka dan segera membuat implementasi yang aman. Secara umum, skema OAuth 2.0 seluler paling aman adalah yang ada di Bagian Apa yang Harus Dilakukan?
  2. Access_token dan data sensitif lainnya: di bawah iOS - di Gantungan Kunci, di bawah Android - di Penyimpanan Internal. Repositori ini dirancang khusus untuk tujuan tersebut. Jika perlu, Anda dapat menggunakan Penyedia Konten di Android, tetapi harus dikonfigurasi dengan aman.
  3. Code harus satu kali, dengan waktu hidup yang singkat.
  4. Untuk melindungi dari intersepsi kode, gunakan code_challenge .
  5. Untuk melindungi dari serangan CSRF pada login, gunakan token CSRF.
  6. Jangan gunakan WebView untuk layar persetujuan, gunakan Tab Kustom Browser.
  7. Client_secret berguna jika tidak disimpan di backend. Jangan berikan kepada klien publik.
  8. Gunakan HTTPS di mana-mana , dengan larangan downgrade ke HTTP.
  9. Ikuti rekomendasi kriptografi (pemilihan sandi, panjang token, dll.) Dari standar . Anda dapat menyalin data dan mencari tahu mengapa itu dilakukan seperti itu, tetapi Anda tidak bisa melakukan kriptografi Anda .
  10. Dari aplikasi klien, verifikasi siapa yang Anda buka untuk OAuth 2.0, dan dari aplikasi penyedia, periksa siapa yang membuka Anda untuk OAuth 2.0.
  11. Waspadai kerentanan OAuth 2.0 yang biasa . Mobile OAuth 2.0 memperluas dan melengkapi yang biasa, jadi tidak ada yang membatalkan cek redirect_uri untuk kecocokan yang tepat dan rekomendasi lain untuk OAuth 2.0 biasa.
  12. Pastikan untuk memberikan SDK kepada pelanggan. Klien akan memiliki lebih sedikit bug dan kerentanan dalam kode, dan akan lebih mudah baginya untuk mengimplementasikan OAuth 2.0 Anda.

Apa yang harus dibaca


  1. [RFC] OAuth 2.0 untuk Aplikasi Asli https://tools.ietf.org/html/rfc8252
  2. Google OAuth 2.0 untuk Aplikasi Seluler & Desktop https://developers.google.com/identity/protocols/OAuth2InstalledApp
  3. [RFC] Kunci Bukti untuk Pertukaran Kode oleh Klien Publik OAuth https://tools.ietf.org/html/rfc7636
  4. Kondisi Balapan OAuth 2.0 https://hackerone.com/reports/55140
  5. [RFC] OAuth 2.0 Model Ancaman dan Pertimbangan Keamanan https://tools.ietf.org/html/rfc6819
  6. Serangan pada OAuth 2.0 biasa https://sakurity.com/oauth
  7. [RFC] OAuth 2.0 Protokol Registrasi Klien Dinamis https://tools.ietf.org/html/rfc7591

Ucapan Terima Kasih


Terima kasih kepada semua orang yang membantu menulis artikel ini, terutama Sergey Belov, Andrey Sumin, Andrey Labunts ( @isciurus ) dan Daria Yakovleva.

Source: https://habr.com/ru/post/id417031/

More articles:


All Articles