# MFA Tidak Cukup untuk Cegah OAuth Consent Abuse > MFA melindungi proses login, tetapi tidak otomatis mencegah penyalahgunaan persetujuan OAuth. Kenali risiko token, scope, dan kontrol consent aplikasi. **URL:** https://www.ciptadusa.com/blog/mfa-tidak-cegah-oauth-consent-abuse-20260921 **Type:** blog **Author:** PT Cipta Dua Saudara **Category:** Keamanan Aplikasi **Published:** 2026-09-21 **Cover:** https://cdn-uagents.enitip.com/uploads/blog/2026-09/daily-appsec-20260921-065711.jpg ## Article MFA melindungi proses masuk ke akun. MFA tidak otomatis mencegah karyawan menyetujui aplikasi OAuth berbahaya. Perbedaan ini penting karena persetujuan OAuth dapat memberi penyerang akses melalui alur kerja cloud yang sah. ## Ringkasan Penyalahgunaan persetujuan OAuth (OAuth consent abuse) terjadi ketika pengguna memberikan izin kepada aplikasi pihak ketiga yang lebih luas dari yang diperkirakan. Penyerang mungkin tidak perlu mencuri kata sandi atau menembus MFA. Serangan berpindah ke tahap otorisasi, ketika alur login yang terlihat biasa dapat menyembunyikan permintaan izin yang berbahaya. ## Mengapa MFA bukan jawaban lengkap Autentikasi multi-faktor memeriksa apakah orang yang masuk memiliki faktor kedua yang diperlukan. Persetujuan OAuth mengajukan pertanyaan yang berbeda: bolehkah aplikasi ini mengakses email, file, profil, atau data bisnis lain milik pengguna? Karena itu, tantangan MFA yang valid tetap bisa diikuti oleh persetujuan yang tidak aman. Pengguna menyelesaikan proses masuk dengan benar, sementara aplikasi menerima token dengan akses yang tidak pernah dimaksudkan oleh tim keamanan. Inilah sebabnya tim identitas perlu memisahkan autentikasi dari otorisasi. MFA memperkuat kontrol pertama, tetapi tidak menggantikan peninjauan kontrol kedua. ## Titik lemah pada persetujuan OAuth Layar persetujuan sering memakai nama izin teknis yang tidak dikenali pengguna biasa. Permintaan untuk membaca email atau mempertahankan akses ke data dapat terlihat seperti pengaturan rutin, terutama jika nama aplikasinya mirip layanan yang sudah dikenal. Penyerang juga dapat memanfaatkan rekayasa sosial. Mereka bisa mengirim tautan yang mengarah ke penyedia identitas asli, lalu meminta pengguna menyetujui sebuah aplikasi. Halaman loginnya asli; bahayanya ada pada apa yang terjadi setelah login. Tim keamanan perlu meninjau pengguna mana yang boleh memberikan persetujuan, aplikasi mana yang tepercaya, dan izin mana yang memerlukan persetujuan administrator. Kebijakan default yang mengizinkan semua persetujuan memberi pengguna tanggung jawab lebih besar daripada yang mungkin disadari organisasi. ## Kontrol yang perlu diperiksa Mulailah dengan membatasi persetujuan pengguna untuk izin berisiko tinggi. Wajibkan persetujuan administrator untuk aplikasi yang meminta akses email, file, direktori, atau akses offline. Kelola inventaris aplikasi perusahaan dan hapus registrasi yang sudah tidak memiliki pemilik. Pantau aplikasi OAuth baru, peristiwa persetujuan yang tidak biasa, aktivitas refresh token, dan akses dari lokasi yang tidak dikenal. Persetujuan yang dibuat oleh pengguna asli tetap perlu diselidiki jika aplikasinya baru, cakupan izin yang diminta luas, atau aktivitas langsung dimulai setelah persetujuan. Gunakan conditional access dan kontrol sesi jika tersedia. Kontrol ini tidak menggantikan tata kelola aplikasi, tetapi dapat mempersempit waktu yang dimiliki penyerang untuk memakai token yang dicuri atau disalahgunakan. ## Apa yang harus dilakukan setelah persetujuan mencurigakan Cabut izin (grant) dan refresh token aplikasi tersebut. Tinjau aktivitas mailbox, file, dan direktori yang terjadi setelah persetujuan. Periksa apakah pengguna juga menyetujui aplikasi yang sama untuk akun lain. Jangan berhenti pada reset kata sandi. Jika penyerang memakai token OAuth, mengganti kata sandi belum tentu membatalkan semua izin yang masih aktif. Respons harus mencakup aplikasi, token, sesi, dan data yang terdampak. Dokumentasikan ID aplikasi, cakupan izin yang diminta, waktu persetujuan, identitas yang menyetujui, dan tindakan yang teramati. Detail ini membantu membedakan persetujuan yang keliru dari kampanye yang terkoordinasi. ## Implikasi untuk pengambil keputusan MFA tetap diperlukan, tetapi hanya mencakup satu bagian dari jalur identitas. Program keamanan cloud yang matang memperlakukan otorisasi pihak ketiga sebagai area kontrol tersendiri, lengkap dengan kebijakan, persetujuan, pemantauan, dan pencabutan. Untuk tim yang meninjau integrasi identitas dan aplikasi bisnis, [tim software house Indonesia yang biasa garap aplikasi custom](https://wa.me/6285792071380) dapat membantu memetakan alur akses dan kontrol yang perlu diuji. ## Referensi - Dark Reading, MFA Won't Save You From OAuth Consent Abuse: https://www.darkreading.com/vulnerabilities-threats/mfa-oauth-consent-abuse - Microsoft Learn, OAuth 2.0 authorization code flow: https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow - Microsoft Learn, Configure user consent settings: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent --- *Markdown version of https://www.ciptadusa.com/blog/mfa-tidak-cegah-oauth-consent-abuse-20260921 — generated for AI agents and LLM crawlers.*