Izin Delegasi vs Izin Aplikasi

By Mirko Peters · 2026-04-26 · Updated 2026-07-18

Bandingkan izin delegasi dan izin aplikasi di Microsoft Entra ID, lalu pilih model akses yang tepat untuk API yang aman, otomasi, dan pengembangan aplikasi.

Automatically translated with AI from the original post. Read the English original

Saat bekerja dengan Microsoft Entra ID, memahami siapa yang boleh melakukan apa, dan dalam kondisi apa, lebih dari sekadar detail teknis. Ini adalah fondasi pengembangan aplikasi yang aman, otomasi, dan pengelolaan identitas secara keseluruhan di cloud Microsoft. Ada perbedaan besar antara membiarkan pengguna memberi aplikasi akses secukupnya untuk bertindak atas nama mereka (izin delegasi) dan memberi aplikasi kunci untuk bertindak secara mandiri (izin aplikasi).

Jika salah memilih, Anda bisa membuka celah bagi paparan data yang tidak diinginkan, masalah kepatuhan, atau bahkan insiden keamanan. Jika tepat, Anda mendapatkan otomasi yang lebih lancar, tata kelola yang lebih jelas, dan auditor yang lebih puas. Panduan ini memberikan gambaran lengkap: seluk-beluk jenis izin ini, bagaimana penerapannya dalam kehidupan nyata, serta semua aspek keamanan, tata kelola, dan operasional yang Anda perlukan untuk membuat pilihan terbaik bagi lingkungan Anda. Mari kita tempatkan izin pada porsinya yang tepat, karena akses yang besar datang dengan tanggung jawab yang besar pula.

Latar Belakang dan Pengantar Model Izin di Identitas Microsoft

Izin di Microsoft Entra ID bukan sekadar kotak centang yang Anda beri tanda; izin adalah kerangka dasar yang tertanam dalam cara aplikasi dan pengguna berinteraksi di Microsoft 365, Azure, dan lainnya. Ketika Microsoft memindahkan identitas ke cloud, mereka membutuhkan cara agar layanan dan alat pihak ketiga dapat berinteraksi secara aman, tanpa begitu saja memberikan akses penuh kepada semua pihak. Di sinilah izin delegasi dan izin aplikasi hadir.

Model ini memungkinkan pengelolaan yang presisi atas siapa yang dapat mengakses apa, dengan batas yang jelas antara apa yang dapat disetujui oleh pengguna secara individu dan apa yang hanya boleh diizinkan oleh administrator. Model ini lahir dari bertahun-tahun pembelajaran (kadang dengan cara yang sulit) dari akun layanan AD klasik dan akses yang kaku, semua atau tidak sama sekali. Memahami model ini bukan sekadar praktik baik, tetapi krusial untuk memenuhi kepatuhan, menerapkan Zero Trust, dan memastikan operasional sehari-hari tidak terhenti akibat salah konfigurasi keamanan.

Izin Aplikasi vs Izin Delegasi: Konsep Inti dan Skenario Dunia Nyata

Mari kita uraikan perbedaan antara izin delegasi dan izin aplikasi dengan bahasa yang sederhana. Anggap izin delegasi sebagai aplikasi yang bertindak sebagai asisten: aplikasi hanya mendapat akses selama pengguna tertentu sedang masuk, dan akses itu dibatasi pada apa yang bisa dilakukan pengguna tersebut. Sebaliknya, izin aplikasi memungkinkan aplikasi Anda bertindak secara mandiri, seperti manajer tanpa pengawasan yang memegang kuncinya sendiri. Aplikasi ini tidak memerlukan kehadiran pengguna sama sekali.

Dengan izin delegasi, autentikasi selalu melibatkan pengguna. Artinya, ketika seseorang masuk, misalnya ke aplikasi yang perlu mengakses email atau kalender mereka, mereka memberi aplikasi jendela waktu sementara untuk beroperasi dengan wewenang mereka. Jika pengguna keluar, jendela tersebut tertutup. Model ini sangat cocok untuk aplikasi yang bekerja atas permintaan pengguna, seperti antarmuka web, bot Teams, atau aplikasi produktivitas seluler.

Dengan izin aplikasi, aplikasi itu sendiri melakukan autentikasi sebagai identitasnya sendiri (perwakilan layanan atau service principal) dan mendapatkan token sendiri. Model inilah yang menggerakkan otomasi dan tugas latar belakang, seperti integrasi sistem yang menyinkronkan data antara SharePoint dan CRM Anda setiap malam. Tidak ada interaksi pengguna yang diperlukan; aplikasi menjalankan tugasnya sesuai jadwal sendiri dan dengan tingkat akses yang disetujui administrator.

Bayangkan Anda perlu mengotomasi pembuatan pengguna: sebuah layanan latar belakang diam-diam memperbarui akun pengguna setiap malam. Dalam kasus ini, izin delegasi tidak berguna karena tidak ada orang yang bisa menyetujui akses. Namun, ketika solusi Anda perlu menawarkan fitur personal saat pengguna sedang aktif, misalnya aplikasi penandatanganan dokumen yang terhubung dengan OneDrive, di situlah izin delegasi bersinar.

Skenario nyata sering kali memerlukan kombinasi keduanya, sehingga memahami model mana yang sesuai dengan kasus penggunaan Anda sangat penting untuk pengalaman pengguna, tata kelola, dan keamanan. Anda tidak ingin memberikan lebih banyak kunci daripada yang dibutuhkan, tetapi Anda juga tidak ingin layanan Anda terkunci pada pukul 3 pagi karena tidak ada orang yang masuk untuk mengotorisasinya.

Di Balik Izin Delegasi Microsoft Entra: Alur Autentikasi dan Batasannya

Izin delegasi di Microsoft Entra ID mengikuti alur autentikasi klasik yang digerakkan oleh pengguna. Alur ini dimulai saat pengguna masuk ke aplikasi Anda menggunakan kredensial Microsoft mereka. Pada titik ini, aplikasi meminta izin tertentu, atau cakupan (scope), sehingga pengguna (dan terkadang admin) dapat melihat dengan jelas jenis data atau tindakan apa yang ingin diakses oleh aplikasi.

Jika izin yang diminta hanya memerlukan persetujuan pengguna, pengguna dapat langsung menyetujuinya melalui layar persetujuan. Untuk izin yang lebih sensitif (misalnya membaca kotak surat seluruh anggota organisasi), diperlukan persetujuan admin. Setelah disetujui, aplikasi Anda menerima token akses yang terikat langsung pada identitas pengguna dan peran yang ditetapkan kepadanya.

Token akses tersebut memungkinkan aplikasi memanggil Microsoft Graph atau API M365, tetapi aplikasi selalu bertindak atas wewenang pengguna. Jadi, jika pengguna adalah karyawan biasa, aplikasi tidak bisa tiba-tiba melompat ke kemampuan admin. Begitu pengguna keluar, akses aplikasi langsung berakhir, sehingga dampak potensial dari penyalahgunaan tetap kecil.

Namun, ada keterbatasannya: izin delegasi tidak berfungsi dalam skenario tanpa pengawasan. Jika Anda menjalankan proses latar belakang, cron job, atau integrasi layanan yang tidak seharusnya bergantung pada pengguna yang sedang aktif masuk, izin delegasi tidak cukup. Semua hal dikaitkan dengan kehadiran pengguna, sehingga tugas dukungan, otomatisasi, dan pekerjaan malam hari akan terhambat.

Ada juga aspek keamanan yang perlu dipertimbangkan. Jika pengguna dengan akses luas tertipu untuk memberikan persetujuan, aplikasi dapat menyalahgunakan izin tersebut. Ini merupakan salah satu vektor utama dalam serangan phishing persetujuan (consent phishing). Karena itu, Anda perlu mengontrol secara ketat siapa yang dapat memberikan izin tertentu, serta memberikan pelatihan kesadaran keamanan tentang makna sebenarnya dari layar persetujuan tersebut.

Over-Permissioning Akses Aplikasi dan Keamanan Token di Microsoft Entra ID

Dalam hal izin, lebih banyak tidak selalu lebih baik. Bahkan, over-permissioning, yaitu memberikan hak istimewa yang tidak perlu atau berlebihan, terutama dengan izin aplikasi, dapat membuka celah bagi kebocoran data sensitif dan insiden keamanan besar. Misalnya, Anda memberi aplikasi akses baca dan tulis ke setiap kotak surat di perusahaan, padahal aplikasi itu hanya perlu membaca acara kalender. Anda baru saja memperbesar permukaan serangan secara signifikan.

Ancaman ini bukan sekadar teori. Penyerang mengeksploitasi penyalahgunaan persetujuan OAuth untuk melewati bahkan autentikasi multi-faktor. Mereka menargetkan pengguna atau admin dengan permintaan persetujuan yang cerdik, lalu memancing mereka untuk menyetujui izin berisiko. Setelah masuk, aplikasi berbahaya tersebut sering kali tetap memiliki akses meskipun kata sandi diganti atau MFA diterapkan. Cengkeraman penyerang tetap bertahan, sehingga pertahanan tradisional menjadi tidak efektif. Untuk pembahasan kasus nyata, lihat penjelasan ini tentang bagaimana penyerang menyalahgunakan persetujuan OAuth di Entra ID serta cara terbaik untuk mengamankannya.

Pembahasan tidak berhenti pada over-permissioning. Token dan kredensial, termasuk client secret dan sertifikat, dapat menjadi target empuk bagi penyerang jika tidak diamankan. Client secret yang bocor dari registrasi aplikasi khusus (app-only) saja sudah cukup bagi penyerang untuk menyamar sebagai layanan Anda. Karena itu, kebersihan kredensial sangat penting: gunakan managed identity jika memungkinkan, rotasi secret secara berkala, dan jangan pernah menyimpan kredensial klien dalam kode atau berkas yang tidak dilindungi. Untuk lingkungan yang bergantung pada akses non-manusia, pertimbangkan Microsoft Entra Workload Identities, yang memungkinkan akses tanpa secret dan dapat diaudit, serta menghilangkan masalah akun layanan lama. Untuk pembahasan lebih mendalam, baca mengapa workload identity wajib untuk Zero Trust.

Terakhir, pemantauan yang tepat itu wajib. Tinjau log masuk dan pemberian OAuth secara rutin, siapkan peringatan untuk persetujuan atau penggunaan token yang mencurigakan, dan selalu waspada terhadap consent phishing serta pencurian token. Temuan dari pelanggaran nyata (seperti rantai serangan Microsoft 365 ini) menunjukkan bahwa penyerang memanfaatkan tata kelola yang lemah, sehingga semakin besar visibilitas, semakin baik. Lindungi kunci, perketat izin, dan pastikan aplikasi Anda tetap berjalan sesuai aturan.

Kontrol dan Praktik Terbaik untuk Mengelola Izin Delegasi dan Izin Aplikasi

• Terapkan Kontrol Bawaan Entra untuk Manajemen IzinManfaatkan alur kerja persetujuan bawaan, proses persetujuan admin, dan kebijakan terperinci dari Microsoft Entra untuk membatasi pengguna atau grup mana yang boleh memberikan izin. Gunakan kebijakan persetujuan admin untuk memastikan hanya aplikasi yang sudah diverifikasi yang menerima cakupan berisiko tinggi.
• Terapkan Prinsip Hak Akses MinimumBerikan aplikasi hanya kumpulan izin minimum yang dibutuhkan untuk fungsinya. Tinjau setiap izin yang diminta selama pendaftaran aplikasi dan hapus izin yang tidak diperlukan. Hak akses minimum adalah pertahanan terkuat Anda terhadap penyalahgunaan dan akses yang melampaui kewenangan.
• Jadwalkan Peninjauan dan Audit Izin Secara BerkalaSiapkan tinjauan akses rutin, dengan memanfaatkan dasbor izin dan persetujuan Entra, untuk mengidentifikasi dan mencabut izin yang tidak digunakan atau berisiko. Otomatisasi pemeriksaan ini bila memungkinkan agar tata kelola dapat diskalakan, sebagaimana diuraikan dalam panduan tata kelola lanjutan seperti strategi Microsoft Purview ini.
• Pantau dan Beri Peringatan atas Perubahan IzinSiapkan pemantauan dan peringatan untuk mendeteksi hibah OAuth baru, lonjakan penggunaan izin aplikasi, atau integrasi admin yang tidak terduga. Pelaporan proaktif memberi Anda waktu untuk merespons sebelum masalah keamanan meningkat.
• Amankan Penyimpanan Token dan KredensialSimpan client secret dan token di brankas aman seperti Azure Key Vault. Rotasi kredensial secara berkala, gunakan sertifikat alih-alih shared secret, dan utamakan workload identity saat mengintegrasikan akses non-manusia, karena identitas tersebut menawarkan manajemen siklus hidup dan kemampuan audit yang lebih baik.
• Adopsi Tata Kelola Lanjutan dan Otomatisasi KebijakanManfaatkan alat seperti Microsoft Purview dan Azure Policy untuk menerapkan kontrol di seluruh penyewa, membagi risiko dengan Data Loss Prevention, serta merancang untuk kepatuhan yang berkelanjutan. Untuk melihat penerapan praktis penggunaan kebijakan untuk tata kelola sejak awal desain, lihat strategi tata kelola perusahaan Azure.

Dengan mengikuti langkah-langkah ini dan memanfaatkan ekosistem alat tata kelola Microsoft, Anda dapat membekali organisasi untuk mengelola risiko izin sebelum berubah menjadi masalah. Edukasi pengguna secara rutin tentang praktik persetujuan yang aman, otomatisasikan sebanyak mungkin, dan ingat bahwa pengelolaan izin tidak pernah selesai sekali saja. Tetap waspada, terus sempurnakan kebijakan, dan lingkungan Entra ID Anda akan tetap berada dalam kondisi baik.

Episode Yang Juga Perlu Anda Dengarkan

Jika Anda sedang menjelajahi delegated vs application permissions Entra ID, episode-episode berikut menambahkan konteks praktis untuk adopsi Microsoft 365 yang aman, perlindungan data, tata kelola, dan manajemen risiko AI.

• Microsoft Purview – Simply Explained — Lihat bagaimana klasifikasi, retensi, kepatuhan, dan perlindungan menyatu dalam satu model tata kelola data Microsoft.
• Microsoft Defender XDR – Simply Explained — Hubungkan kontrol perlindungan data dengan deteksi, investigasi, dan respons.
• Conditional Access – Simply Explained — Pahami bagaimana sinyal identitas dan risiko menambahkan konteks pada keputusan akses.
• Microsoft AI Agent Harness – Simply Explained — Jelajahi kontrol yang membuat otomatisasi AI lebih andal, dapat diamati, dan aman.

Episode-episode ini membantu mengubah konsep dalam artikel menjadi keputusan desain dan implementasi yang praktis.