Popularitas aplikasi seluler terus meningkat. Begitu juga protokol OAuth 2.0 pada aplikasi seluler. Itu tidak cukup untuk menerapkan standar seperti membuat protokol OAuth 2.0 aman di sana. Seseorang perlu mempertimbangkan spesifikasi aplikasi seluler dan menerapkan beberapa mekanisme keamanan tambahan.

Pada artikel ini, saya ingin berbagi konsep serangan OAuth 2.0 seluler dan mekanisme keamanan yang digunakan untuk mencegah masalah tersebut. Konsep yang dijelaskan bukan hal baru tetapi ada kekurangan informasi terstruktur tentang topik ini. Tujuan utama artikel ini adalah untuk mengisi celah ini.

OAuth 2.0 sifat dan tujuan

OAuth 2.0 adalah protokol otorisasi yang menjelaskan cara layanan klien untuk mendapatkan akses yang aman ke sumber daya pengguna pada penyedia layanan. Berkat OAuth 2.0, pengguna tidak perlu memasukkan kata sandi di luar penyedia layanan: seluruh proses dikurangi dengan mengklik tombol "Saya setuju untuk memberikan akses ke ...".

Penyedia adalah layanan yang memiliki data pengguna dan, dengan izin pengguna, memberikan layanan pihak ketiga (klien) dengan akses yang aman ke data ini. Klien adalah aplikasi yang ingin menyimpan data pengguna oleh penyedia.

Segera setelah protokol OAuth 2.0 dirilis, protokol ini diadaptasi untuk otentikasi , meskipun tidak dimaksudkan untuk itu. Menggunakan OAuth 2.0 untuk otentikasi menggeser vektor serangan dari data yang disimpan di penyedia layanan ke akun pengguna layanan klien.

Tetapi otentikasi hanyalah permulaan. Pada saat aplikasi seluler dan pemuliaan konversi, mengakses aplikasi hanya dengan satu tombol terdengar bagus. Pengembang mengadaptasi OAuth 2.0 untuk penggunaan mobile. Tentu saja, tidak banyak yang khawatir tentang keamanan dan spesifikasi aplikasi seluler: zap dan masuk ke dalam produksi mereka pergi! Kemudian lagi, OAuth 2.0 tidak berfungsi dengan baik di luar aplikasi web: ada masalah yang sama di aplikasi seluler dan desktop.

Jadi, mari kita cari tahu cara membuat ponsel OAuth 2.0 aman.

Bagaimana cara kerjanya?

Ada dua masalah keamanan OAuth 2.0 seluler utama:

1. Klien tidak tepercaya. Beberapa aplikasi seluler tidak memiliki backend untuk OAuth 2.0, sehingga bagian klien dari aliran protokol berjalan di perangkat seluler.
   
2. Pengalihan dari browser ke aplikasi seluler berperilaku berbeda tergantung pada pengaturan sistem, urutan aplikasi yang diinstal dan sihir lainnya.
   

Mari kita lihat lebih dalam masalah ini.

Aplikasi seluler adalah klien publik

Untuk memahami akar dan konsekuensi dari masalah pertama, mari kita lihat bagaimana OAuth 2.0 bekerja dalam kasus interaksi server-ke-server dan kemudian membandingkannya dengan OAuth 2.0 dalam hal interaksi klien-ke-server.

Dalam kedua kasus, semuanya dimulai dengan register layanan klien pada layanan provider dan menerima client_id dan , dalam beberapa kasus , client_secret. client_id , client_secret. client_id adalah nilai publik, dan itu diperlukan untuk identifikasi layanan klien yang bertentangan dengan nilai client_secret , yang bersifat pribadi. Anda dapat membaca lebih lanjut tentang proses pendaftaran di RFC 7591 .

Skema di bawah ini menunjukkan cara OAuth 2.0 beroperasi dalam hal interaksi server-ke-server.


Asal gambar: https://tools.ietf.org/html/rfc6749#section-1.2

Protokol OAuth 2.0 dapat dibagi menjadi tiga langkah utama:

1. [langkah AC] Terima code authorization_code (selanjutnya, code ).
   
2. [langkah DE] Pertukarkan code ke access_token .
   
3. Dapatkan sumber daya melalui access_token .

Mari kita uraikan proses mendapatkan nilai code :

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

Mari kita bicara lebih banyak tentang proses mendapatkan access_token :

1. [Langkah D] Server klien mengirimkan permintaan untuk access_token . Code , client_secret dan redirect_uri termasuk dalam permintaan.
   
2. [Langkah E] Dalam kasus code valid, client_secret dan redirect_uri , access_token disediakan.
   

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

Sekarang mari kita lihat skema mobile OAuth 2.0 tanpa backend (interaksi client-to-server).


Asal gambar: https://tools.ietf.org/html/rfc8252#section-4.1

Skema utama dibagi menjadi beberapa langkah utama yang sama:

1. [langkah 1-4 dalam gambar] Dapatkan code .
2. [langkah 5-6 dalam gambar] Pertukarkan code ke access_token
3. Dapatkan akses sumber daya melalui access_token

Namun, dalam hal ini aplikasi seluler juga memiliki fungsi server; Oleh karena itu, client_secret akan tertanam ke dalam aplikasi. Akibatnya, client_secret tidak dapat disembunyikan dari penyerang di perangkat seluler. client_secret dapat diekstraksi dengan dua cara: dengan menganalisis lalu lintas aplikasi ke server atau dengan rekayasa terbalik. Keduanya dapat dengan mudah diimplementasikan, dan itulah sebabnya client_secret tidak berguna di perangkat seluler.

Anda mungkin bertanya: "Mengapa kita tidak segera mendapatkan access_token ?" Anda mungkin berpikir bahwa langkah tambahan ini tidak perlu. Selain itu ada skema Hibah Implisit yang memungkinkan klien untuk menerima access_token segera. Meskipun, dalam beberapa kasus, ini dapat digunakan, Implisit Grant tidak akan berfungsi untuk ponsel aman OAuth 2.0.

Pengalihan pada perangkat seluler

Secara umum, Skema URI Khusus dan mekanisme AppLink digunakan untuk pengalihan browser-ke-aplikasi. Tidak satu pun dari mekanisme ini yang dapat seaman peramban mengarahkan sendiri.

Skema URI khusus (atau tautan dalam) digunakan dengan cara berikut: pengembang menentukan skema aplikasi sebelum penyebaran. Skema dapat berupa apa saja, dan satu perangkat dapat memiliki beberapa aplikasi dengan skema yang sama.

Itu membuat segalanya lebih mudah ketika setiap skema pada perangkat sesuai dengan satu aplikasi. Tetapi bagaimana jika dua aplikasi mendaftarkan skema yang sama pada satu perangkat? Bagaimana sistem operasi memutuskan aplikasi mana yang akan dibuka ketika dihubungi melalui Skema URI Khusus? Android akan menampilkan jendela dengan pilihan aplikasi dan tautan untuk diikuti. iOS tidak memiliki prosedur untuk ini dan, oleh karena itu, aplikasi mana pun dapat dibuka. Bagaimanapun, penyerang mendapat kesempatan untuk mencegat kode atau access_token .

Tidak seperti Skema URI Kustom, AppLink menjamin untuk membuka aplikasi yang tepat, tetapi mekanisme ini memiliki beberapa kelemahan:

1. Setiap klien layanan harus menjalani prosedur verifikasi .
   
2. Pengguna Android dapat mematikan AppLink untuk aplikasi tertentu dalam pengaturan.
   
3. Versi Android yang lebih lama dari 6.0 dan versi iOS yang lebih tua dari 9.0 tidak mendukung AppLink.
   

Semua kekurangan AppLink ini meningkatkan kurva belajar untuk klien layanan potensial dan dapat mengakibatkan kegagalan pengguna OAuth 2.0 dalam beberapa keadaan. Itu sebabnya banyak pengembang tidak memilih mekanisme AppLink sebagai pengganti peralihan browser dalam protokol OAuth 2.0.

Oke, apa yang bisa diserang?

Masalah Mobile OAuth 2.0 telah menciptakan beberapa serangan spesifik. Mari kita lihat siapa mereka dan bagaimana mereka bekerja.

Serangan Intersepsi Kode Otorisasi

Mari kita pertimbangkan situasi di mana perangkat pengguna memiliki aplikasi yang sah (klien OAuth 2.0) dan aplikasi jahat yang mendaftarkan skema yang sama dengan yang sah. Gambar di bawah ini menunjukkan skema serangan.


Asal gambar https://tools.ietf.org/html/rfc7636#section-1

Inilah masalahnya: pada langkah keempat, browser mengembalikan code dalam aplikasi melalui Skema URI Kustom dan, oleh karena itu, code dapat dicegat oleh aplikasi jahat (karena terdaftar skema yang sama dengan aplikasi yang sah). Kemudian aplikasi jahat mengubah code ke access_token dan menerima akses ke data pengguna.

Apa perlindungannya? Dalam beberapa kasus, Anda dapat menggunakan komunikasi antar-proses; kita akan membicarakannya nanti. Secara umum, Anda memerlukan skema yang disebut Kunci Bukti untuk Pertukaran Kode . Itu dijelaskan dalam skema di bawah ini.


Asal gambar: https://tools.ietf.org/html/rfc7636#section-1.1

Permintaan klien memiliki beberapa parameter tambahan: code_verifier , code_challenge (dalam skema t(code_verifier) ) dan code_challenge_method (dalam skema t_m ).

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

Code_challenge_method - ini adalah nama fungsi konversi, sebagian besar SHA-256.

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

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

Jika perangkat pengguna tidak mendukung SHA-256, client is allowed to use plain conversion of code_verifier . Dalam semua kasus lain, SHA-256 harus digunakan.

Beginilah skema ini bekerja:

1. Klien membuat code_verifier dan menghafalnya.
   
2. Klien memilih code_challenge_method dan menerima 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 menyimpan code_challenge dan code_challenge_method di server dan mengembalikan code ke klien.
   
5. [Langkah C] Klien meminta access_token , dengan code_verifier ditambahkan padanya.
   
6. Penyedia menerima code_challenge dari code_challenge masuk, dan kemudian membandingkannya dengan code_challenge , yang disimpannya.
   
7. [Langkah D] Jika nilainya cocok, penyedia memberi klien access_token .
   

Untuk memahami mengapa code_challenge intersepsi kode, mari kita lihat bagaimana aliran protokol terlihat dari perspektif penyerang.

1. Pertama, code permintaan aplikasi yang sah ( code_challenge dan code_challenge_method dikirim bersama dengan permintaan ).
   
2. code intersep aplikasi berbahaya (tetapi bukan code_challenge , karena kode _challenge tidak ada dalam respons).
   
3. Aplikasi berbahaya meminta access_token (dengan code valid, tetapi tanpa code_verifier valid).
   
4. Server memperhatikan ketidakcocokan code_challenge dan memunculkan pesan kesalahan.
   

Perhatikan bahwa penyerang tidak dapat menebak code_verifier (nilai 256 bit acak!) Atau menemukannya di suatu tempat di log (karena permintaan pertama benar-benar dikirimkan code_challenge ).

Jadi, code_challenge menjawab pertanyaan dari penyedia layanan: "Apakah access_token diminta oleh klien aplikasi yang sama yang meminta code atau yang berbeda?".

OAuth 2.0 CSRF

OAuth 2.0 CSRF relatif tidak berbahaya ketika OAuth 2.0 digunakan untuk otorisasi. Ini adalah cerita yang sama sekali berbeda ketika OAuth 2.0 digunakan untuk otentikasi. Dalam hal ini OAuth 2.0, CSRF sering mengarah pada pengambilalihan akun.

Mari kita bicara lebih banyak tentang serangan CSRF yang sesuai dengan OAuth 2.0 melalui contoh klien aplikasi taksi dan penyedia provider.com. Pertama, seorang penyerang di perangkatnya sendiri masuk ke akun attacker@provider.com dan menerima code untuk taksi. Kemudian dia menghentikan proses OAuth 2.0 dan menghasilkan tautan:

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

Kemudian penyerang mengirimkan tautan ini kepada korbannya, misalnya, dalam bentuk surat atau pesan teks dari taksi. Korban mengklik tautan, aplikasi taksi membuka dan menerima access_token . Akibatnya, mereka menemukan diri mereka di akun taksi penyerang . Tidak menyadari itu, korban menggunakan akun ini: melakukan perjalanan, memasukkan data pribadi, dll.

Sekarang penyerang dapat login ke akun taksi korban kapan saja, karena terhubung ke attacker@provider.com . Serangan login CSRF memungkinkan pelanggar untuk mencuri akun.

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

1. Aplikasi klien menghasilkan dan menyimpan token CSRF di perangkat seluler klien.
   
2. Aplikasi klien mencakup token CSRF dalam permintaan akses code .
   
3. Server mengembalikan token CSRF yang sama dengan code dalam tanggapannya.
   
4. Aplikasi klien membandingkan token CSRF yang masuk dan disimpan. Jika nilainya cocok, prosesnya berjalan.
   

Persyaratan token CSRF: nonce harus minimal 256 bit dan diterima dari sumber sekuens pseudo-acak yang baik.

Singkatnya, token CSRF memungkinkan klien aplikasi untuk menjawab pertanyaan berikut: "Apakah itu saya yang memprakarsai permintaan access_token atau seseorang mencoba menipu saya?".

Rahasia klien dengan hardcode

Aplikasi seluler tanpa backend terkadang menyimpan nilai-nilai client_id dan client_secret hardcode. Tentu saja mereka dapat dengan mudah diekstraksi dengan aplikasi reverse engineering.

Dampak mengekspos client_id dan client_secret sangat tergantung pada seberapa banyak penyedia layanan kepercayaan menaruh pada client_id , pair client_secret tertentu. Satu menggunakannya hanya untuk membedakan satu klien dari yang lain sementara yang lain membuka titik akhir API tersembunyi atau membuat batas tingkat yang lebih lunak untuk beberapa klien.

Artikel Mengapa Kunci dan Rahasia OAuth API Tidak Aman di Aplikasi Seluler menjelaskan lebih lanjut tentang topik ini.

Aplikasi berbahaya bertindak sebagai klien yang sah

Beberapa aplikasi jahat dapat meniru aplikasi yang sah dan menampilkan layar persetujuan atas nama mereka (layar persetujuan adalah layar tempat pengguna melihat: "Saya setuju untuk memberikan akses ke ..."). Pengguna dapat mengklik "izinkan" dan berikan datanya aplikasi berbahaya kepada.

Android dan iOS menyediakan mekanisme aplikasi pemeriksaan silang. Penyedia aplikasi dapat memastikan bahwa aplikasi klien itu sah dan sebaliknya.

Sayangnya, jika mekanisme OAuth 2.0 menggunakan utas melalui peramban, tidak mungkin untuk bertahan melawan serangan ini.

Serangan lainnya

Kami melihat lebih dekat pada serangan eksklusif untuk ponsel OAuth 2.0. Namun, jangan lupa tentang OAuth 2.0 asli: substitusi redirect_uri , intersepsi lalu lintas melalui koneksi tidak aman, dll. Anda dapat membaca lebih lanjut di sini .

Bagaimana cara melakukannya dengan aman?

Kami telah mempelajari cara kerja protokol OAuth 2.0 dan kerentanan apa yang dimilikinya pada perangkat seluler. Sekarang mari kita pisahkan bagian-bagian yang terpisah untuk memiliki skema OAuth 2.0 seluler yang aman.

Bagus, buruk OAuth 2.0

Mari kita mulai dengan cara yang benar untuk menggunakan layar persetujuan. Perangkat seluler memiliki dua cara untuk membuka halaman web dalam aplikasi seluler.



Cara pertama adalah melalui Browser Custom Tab (di sebelah kiri dalam gambar). Catatan : Browser Custom Tab untuk Android disebut Chrome Custom Tab, dan untuk iOS - SafariViewController. Itu hanya tab browser yang ditampilkan di aplikasi: tidak ada peralihan visual di antara aplikasi.

Cara kedua adalah melalui WebView (di sebelah kanan dalam gambar) dan saya menganggapnya buruk sehubungan dengan ponsel OAuth 2.0.

WebView adalah browser tertanam untuk aplikasi seluler.

" Browser tertanam " berarti akses ke cookie, penyimpanan, cache, riwayat, dan data Safari serta Chrome lainnya dilarang untuk WebView. Kebalikannya juga benar: Safari dan Chrome tidak bisa mendapatkan akses ke data WebView.

" Browser aplikasi seluler " berarti aplikasi seluler yang menjalankan WebView memiliki akses penuh ke cookie, penyimpanan, cache, riwayat, dan data WebView lainnya.

Sekarang, bayangkan: pengguna mengklik "masuk dengan ..." dan WebView dari aplikasi jahat meminta login dan kata sandinya dari penyedia layanan.

Gagal epik:

1. Pengguna memasukkan login dan kata sandi untuk akun penyedia layanan di aplikasi, yang dapat dengan mudah mencuri data ini.
   
2. OAuth 2.0 pada awalnya dikembangkan untuk tidak memasukkan login dan kata sandi penyedia layanan.
   
   Pengguna terbiasa memasukkan login dan kata sandi di mana saja sehingga meningkatkan kemungkinan memancing .
   

Mempertimbangkan semua kontra WebView, kesimpulan yang jelas menawarkan dirinya sendiri: gunakan Tab Kustom Browser untuk layar persetujuan.

Jika ada orang yang mendukung WebView alih-alih Tab Kustom Browser, saya sangat menghargai jika Anda menulisnya di komentar.

Skema OAuth 2.0 seluler yang aman

Kita akan menggunakan skema Pemberian Kode Otorisasi, karena memungkinkan kita untuk menambahkan code_challenge serta state dan mempertahankan terhadap serangan intersepsi kode dan OAuth 2.0 CSRF.


Asal gambar: https://tools.ietf.org/html/rfc8252#section-4.1

Permintaan akses kode (langkah 1-2) akan terlihat sebagai berikut:

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

Pada langkah 3, browser mendapat respons dengan mengalihkan:

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

Pada langkah 4, browser membuka Skema URI Khusus dan memberikan token CSRF ke aplikasi klien.
permintaan access_token (langkah 5):

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

Langkah terakhir membawa respons dengan access_token .

Skema ini umumnya aman, tetapi ada beberapa kasus khusus ketika OAuth 2.0 bisa lebih sederhana dan lebih aman.

Android IPC

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

1. Aplikasi yang membuka saluran IPC dapat mengkonfirmasi keaslian aplikasi yang dibuka oleh sertifikatnya. Kebalikannya juga benar: aplikasi yang dibuka dapat mengkonfirmasi keaslian aplikasi yang membukanya.
   
2. Jika pengirim mengirim permintaan melalui saluran IPC, ia dapat menerima jawaban melalui saluran yang sama. Bersama dengan cross-check (item 1), itu berarti bahwa tidak ada proses asing yang dapat mencegat access_token .
   

Oleh karena itu, kita dapat menggunakan Implisit Hibah untuk menyederhanakan skema OAuth 2.0 seluler. Tidak ada code_challenge dan state juga berarti lebih sedikit permukaan serangan. Kami juga dapat menurunkan risiko aplikasi jahat bertindak seperti klien yang sah yang mencoba mencuri akun pengguna.

SDK untuk klien

Selain menerapkan skema OAuth 2.0 seluler yang aman ini, penyedia harus mengembangkan SDK untuk kliennya. Ini akan menyederhanakan implementasi OAuth 2.0 di sisi klien dan sekaligus mengurangi jumlah kesalahan dan kerentanan.

Kesimpulan

Biarkan saya meringkasnya untuk Anda. Berikut adalah daftar periksa (dasar) untuk OAuth 2.0 yang aman untuk penyedia OAuth 2.0:

1. Fondasi yang kuat sangat penting. Dalam hal mobile OAuth 2.0, yayasan adalah skema atau protokol yang dipilih untuk implementasi. Sangat mudah untuk membuat kesalahan saat menerapkan skema OAuth 2.0 Anda sendiri . Yang lain sudah mengetuk dan mempelajari pelajaran mereka; tidak ada yang salah dengan belajar dari kesalahan mereka dan membuat implementasi yang aman dalam sekali jalan. Skema OAuth 2.0 seluler yang paling aman dijelaskan dalam Bagaimana melakukannya dengan aman ?
   
2. Access_token dan data sensitif lainnya harus disimpan di Keychain untuk iOS dan di Penyimpanan Internal untuk Android. Penyimpanan ini secara khusus dikembangkan hanya untuk itu. Penyedia Konten dapat digunakan di Android, tetapi harus dikonfigurasi dengan aman.
   
3. Client_secret tidak berguna , kecuali disimpan di backend. Jangan memberikannya kepada klien publik.
   
4. Jangan gunakan WebView untuk layar persetujuan; gunakan tab khusus browser.
   
5. Untuk bertahan melawan serangan intersepsi kode, gunakan code_challenge .
   
6. Untuk mempertahankan diri dari OAuth 2.0 CSRF, gunakan state .
   
7. Gunakan HTTPS di mana-mana , dengan downgrade dilarang ke HTTP. Berikut ini adalah demo 3 menit yang menjelaskan alasannya (dengan contoh dari bug bug).
   
8. Ikuti standar kriptografi (pilihan algoritma, panjang token, dll). Anda dapat menyalin data dan mencari tahu mengapa itu dilakukan dengan cara ini, tetapi jangan roll crypto Anda sendiri.
   
9. Code harus digunakan hanya sekali, dengan umur yang pendek.
   
10. Dari sisi klien aplikasi, periksa apa yang Anda buka untuk OAuth 2.0; dan dari sisi penyedia aplikasi, periksa siapa yang membuka Anda untuk OAuth 2.0.
    
11. Ingatlah kerentanan OAuth 2.0 yang umum . Mobile OAuth 2.0 memperbesar dan melengkapi yang asli, oleh karena itu, redirect_uri memeriksa kecocokan yang tepat dan rekomendasi lain untuk OAuth 2.0 asli masih berlaku.
    
12. Anda harus memberi klien Anda SDK. Mereka akan memiliki lebih sedikit bug dan kerentanan dan akan lebih mudah bagi mereka untuk mengimplementasikan OAuth 2.0 Anda.
    

Bacaan lebih lanjut

1. "Kerentanan OAuth 2.0 seluler" " https://www.youtube.com/watch?v=vjCF_O6aZIg
   
2. Penelitian kondisi ras OAuth 2.0 https://hackerone.com/reports/55140
   
3. Hampir semuanya tentang OAuth 2.0 di satu tempat https://oauth.net/2/
   
4. Mengapa Kunci dan Rahasia OAuth API Tidak Aman di Aplikasi Seluler https://developer.okta.com/blog/2019/01/22/oauth-api-keys-arent-safe-in-mobile-apps
   
5. [RFC] OAuth 2.0 untuk Aplikasi Asli https://tools.ietf.org/html/rfc8252
   
6. [RFC] Kunci Bukti untuk Pertukaran Kode oleh Klien Publik OAuth https://tools.ietf.org/html/rfc7636
   
7. [RFC] OAuth 2.0 Model Ancaman dan Pertimbangan Keamanan https://tools.ietf.org/html/rfc6819
   
8. [RFC] OAuth 2.0 Protokol Registrasi Klien Dinamis https://tools.ietf.org/html/rfc7591
   
9. Google OAuth 2.0 untuk Aplikasi Seluler & Desktop https://developers.google.com/identity/protocols/OAuth2InstalledApp
   

Kredit

Terima kasih untuk semua yang membantu saya menulis artikel ini. Terutama kepada Sergei Belov, Andrei Sumin, Andrey Labunets untuk umpan balik tentang perincian teknis, kepada Pavel Kruglov untuk terjemahan bahasa Inggris dan kepada Daria Yakovleva untuk bantuan dengan merilis versi Rusia dari artikel ini.