Izin Delegasi vs. Izin Aplikasi: Memilih Model yang Tepat untuk Aplikasi Anda

By Mirko Peters · 2026-08-11

Selamat datang kembali di podcast dan seri kami yang berkelanjutan untuk membantu Anda menguasai Microsoft 365, Azure, dan alat pengembang yang menggerakkan ekosistem cloud modern. Jika Anda pernah membangun integrasi, menulis skrip, atau menerapkan otomatisasi perusahaan menggunakan Microsoft Graph API, Anda pasti pernah menghadapi tembok izin. Mengamankan penyewa sambil membangun aplikasi yang f

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

Selamat datang kembali di podcast dan seri kami yang berkelanjutan untuk membantu Anda menguasai Microsoft 365, Azure, dan alat pengembang yang menggerakkan ekosistem cloud modern. Jika Anda pernah membangun integrasi, menulis skrip, atau menerapkan otomatisasi perusahaan menggunakan Microsoft Graph API, Anda pasti pernah menghadapi tembok izin. Mengamankan penyewa sambil membangun aplikasi yang fungsional adalah salah satu keseimbangan paling krusial yang akan Anda hadapi sebagai administrator atau pengembang. Memilih di antara model izin yang berbeda berdampak langsung pada postur keamanan, kecepatan penerapan, dan arsitektur sistem secara keseluruhan.

Untuk membahas topik kompleks ini lebih dalam, kami baru-baru ini merekam episode yang mengupas tuntas. Pastikan Anda menyimak diskusi audio lengkapnya di Microsoft Graph Permissions and Consent Models Explained. Dalam artikel blog pendamping ini, kami akan mengulas lebih jauh konsep-konsep tersebut, menguji perbedaan mendasar antara izin delegasi dan izin aplikasi, meninjau model persetujuan, membahas praktik terbaik, serta menyajikan kerangka kerja menyeluruh agar aplikasi Anda tetap aman dan patuh.

Ikhtisar Izin Microsoft Graph API

Sebelum masuk ke seluk-beluk alur otorisasi tertentu, ada baiknya memahami apa sebenarnya izin Microsoft Graph API itu. Pada intinya, Microsoft Graph berfungsi sebagai gerbang terpadu ke data yang tersimpan di seluruh layanan Microsoft 365, termasuk Exchange Online, SharePoint, Microsoft Teams, OneDrive, dan Azure Active Directory (Microsoft Entra ID). Alih-alih memaksa pengembang untuk melakukan autentikasi ke banyak endpoint yang terpisah, Microsoft Graph menyediakan satu endpoint REST API. Namun, karena API ini membuka akses ke hampir setiap sudut aset digital sebuah organisasi, pengamanannya memerlukan kerangka izin yang kokoh dan terperinci.

Izin Delegasi vs Izin Aplikasi

Ketika Anda mendaftarkan aplikasi di platform identitas Microsoft, Anda harus secara eksplisit menyatakan bagaimana aplikasi Anda berniat berinteraksi dengan sumber daya. Pada dasarnya, ini bermuara pada pilihan antara dua jenis izin utama: izin delegasi dan izin aplikasi. Pilihan ini menentukan bagaimana aplikasi Anda melakukan autentikasi, siapa atau apa yang diwakilinya, serta batas data yang dapat diambilnya.

Izin delegasi dirancang untuk aplikasi sisi klien atau aplikasi yang berinteraksi langsung dengan pengguna, seperti aplikasi web satu halaman, aplikasi seluler, atau utilitas desktop, di mana pengguna yang sudah masuk benar-benar hadir. Dalam model ini, aplikasi Anda beroperasi *atas nama* pengguna. Aplikasi hanya dapat mengakses data dan melakukan tindakan yang memang memiliki hak untuk dilakukan oleh pengguna tersebut. Saat pengguna membuka aplikasi, mereka diminta untuk masuk dan memberikan persetujuan secara eksplisit, lalu sebuah token akses OAuth 2.0 diterbitkan yang berisi identitas pengguna sekaligus cakupan izin yang disetujui.

Sebaliknya, izin aplikasi digunakan oleh layanan latar belakang, daemon, web job, dan runbook otomatis yang beroperasi secara independen dari konteks pengguna mana pun. Di sini, aplikasi berjalan dengan identitasnya sendiri. Aplikasi memanfaatkan kredensial klien, seperti rahasia klien, pasangan kunci sertifikat publik/privat, atau identitas terkelola, untuk memperoleh token akses khusus aplikasi dari Azure AD. Karena tidak ada pengguna manusia yang duduk di depan keyboard untuk melakukan autentikasi, izin ini mencakup sumber daya di seluruh penyewa. Akibatnya, izin ini membawa risiko keamanan yang jauh lebih tinggi dan selalu memerlukan persetujuan eksplisit dari administrator penyewa.

Perbedaan Utama dan Kasus Penggunaan

Memahami kapan menerapkan setiap model izin dapat mencegah hambatan arsitektur dan kerentanan keamanan. Mari kita lihat rincian perbandingan singkatnya:

• Izin Delegasi: Aplikasi bekerja untuk pengguna. Pengguna harus masuk dan memberikan persetujuan. Aplikasi hanya dapat melihat apa yang bisa dilihat pengguna. Model ini ideal untuk aplikasi klien yang membaca atau menulis data pribadi, seperti kalender atau email individual.
• Izin Aplikasi: Aplikasi bekerja sebagai dirinya sendiri. Tidak ada pengguna yang perlu masuk. Administrator harus memberikan persetujuan. Aplikasi dapat melihat dan mengubah data di seluruh penyewa. Model ini ideal untuk sinkronisasi latar belakang, pelaporan administratif, dan pekerjaan tata kelola otomatis.

Memilih model yang tepat sepenuhnya bergantung pada arsitektur aplikasi Anda. Misalnya, jika Anda membangun dasbor interaktif yang menampilkan profil pengguna dan kotak masuk pribadinya, Anda harus menggunakan izin delegasi. Sebaliknya, jika Anda mengembangkan skrip otomatis yang memindai semua kotak surat di seluruh organisasi setiap tengah malam untuk audit kepatuhan, izin aplikasi diperlukan.

Izin Delegasi di Microsoft Graph

Cara Kerja Izin Delegasi

Akses delegasi sangat terkait dengan identitas pengguna. Ketika aplikasi Anda meminta izin delegasi, pada dasarnya aplikasi meminta izin kepada server otorisasi untuk meniru pengguna yang sedang masuk dalam batas yang telah ditentukan. Token akses yang dikembalikan melalui alur kode otorisasi OAuth berisi klaim cakupan (scope) tertentu yang mencerminkan hak intrinsik pengguna sekaligus izin yang diminta aplikasi.

• Akses delegasi berarti aplikasi Anda bertindak langsung sebagai pengguna.
• Baik pendaftaran aplikasi maupun pengguna individu harus memiliki hak dasar yang sesuai.
• Cakupan menentukan batas tertinggi dari apa yang dapat dilakukan aplikasi Anda atas nama pengguna.
• Token akses yang dihasilkan menggabungkan identitas aplikasi dan konteks pengguna.

Skenario Umum untuk Izin Delegasi

Izin delegasi mendukung sebagian besar integrasi produktivitas sehari-hari. Misalnya, jika aplikasi pencatat catatan perusahaan perlu menyinkronkan berkas ke OneDrive pengguna, aplikasi tersebut meminta cakupan Files.ReadWrite. Jika pengguna tidak memiliki izin untuk mengakses dokumen tertentu, Graph API akan menolak permintaan tersebut, meskipun cakupan aplikasi secara teknis mengizinkannya. Demikian pula, aplikasi yang menggunakan Microsoft Graph SDK untuk mengirim notifikasi email otomatis atas nama pengguna memanfaatkan cakupan delegasi seperti Mail.Send.

Pertimbangan Keamanan dan Persetujuan

Meskipun izin delegasi secara inheren lebih aman daripada izin aplikasi tingkat penyewa karena dibatasi oleh hak pengguna, izin ini tetap menghadirkan tantangan keamanan tersendiri. Jika aplikasi meminta cakupan yang terlalu luas, seperti akses penuh ke seluruh kotak surat dan profil direktori pengguna, serangan phishing yang berhasil atau kompromi aplikasi dapat mengekspos data pribadi yang sensitif. Pengembang harus benar-benar mematuhi prinsip hak akses minimum, dengan hanya meminta cakupan yang benar-benar dibutuhkan untuk fungsi yang segera diperlukan.

Izin Aplikasi di Microsoft Graph

Cara Kerja Izin Aplikasi

Izin aplikasi menghilangkan unsur manusia dari proses autentikasi. Alih-alih berinteraksi dengan permintaan masuk, aplikasi mengautentikasi langsung ke Microsoft Entra ID menggunakan kredensial klien. Token yang dihasilkan berisi peran aplikasi, bukan cakupan delegasi, sehingga memberikan akses luas dan tidak terbatas kepada service principal ke seluruh sumber daya di dalam penyewa.

• Izin aplikasi berfungsi sepenuhnya tanpa pengguna yang sedang masuk.
• Aplikasi memperoleh token khusus aplikasi untuk membuat kueri sumber daya.
• Akses diatur oleh peran aplikasi yang ditetapkan pada service principal, bukan oleh hak istimewa pengguna individu.

Kapan Menggunakan Izin Aplikasi

Anda sebaiknya membatasi izin aplikasi secara ketat pada beban kerja backend, daemon tanpa pengawasan, dan integrasi sistem-ke-sistem. Contohnya mencakup mesin provisioning pengguna otomatis, sistem cadangan terpusat, alat respons insiden keamanan, dan skrip migrasi penyewa.

Persetujuan Admin dan Implikasi Keamanan

Karena izin aplikasi melewati batasan pengguna individu dan memberikan akses tingkat penyewa, pengguna biasa tidak dapat menyetujuinya. Hanya administrator dengan hak istimewa yang dapat memberikan persetujuan aplikasi. Konfigurasi izin aplikasi yang keliru, seperti memberikan Directory.ReadWrite.All atau Mail.ReadWrite.All kepada aplikasi latar belakang yang tidak tepercaya atau buruk kodenya, dapat membuat seluruh penyewa Microsoft 365 rentan terhadap kompromi total. Selalu audit service principal aplikasi perusahaan Anda secara berkala.

Kelebihan dan Kekurangan Izin Microsoft Graph API

Kelebihan

• Model izin terpadu: Satu kerangka otorisasi yang konsisten di seluruh layanan Microsoft 365 menyederhanakan administrasi.
• Cakupan terperinci: Cakupan delegasi dan aplikasi yang granular memungkinkan arsitektur hak akses minimum yang presisi.
• OAuth2/OpenID Connect standar: Memanfaatkan protokol keamanan standar industri untuk integrasi identitas yang sederhana.
• Integrasi RBAC: Terhubung secara mulus dengan peran Azure AD dan kebijakan Akses Bersyarat untuk kepatuhan yang terpusat.
• Persetujuan bertahap: Memungkinkan aplikasi meminta izin tambahan seiring waktu, alih-alih menuntut semua izin di awal.

Kekurangan

• Kompleksitas: Memahami keterkaitan antara scope delegasi, peran aplikasi, dan model persetujuan admin bisa membingungkan bagi pemula.
• Risiko izin tingkat tinggi: Salah konfigurasi izin yang luas (seperti Sites.FullControl.All) dapat mengekspos data perusahaan dalam jumlah besar.
• Hambatan persetujuan admin: Mewajibkan persetujuan administratif untuk izin berdampak tinggi dapat memperlambat siklus pengembangan yang gesit.
• Dokumentasi yang tersebar: Pengembang sering harus membandingkan beberapa repositori dokumentasi Microsoft untuk memetakan perilaku API yang tepat.

Model Persetujuan dan Praktik Terbaik

Persetujuan Pengguna vs Admin di Microsoft Graph

Mengelola cara persetujuan diperoleh sangat penting untuk tata kelola organisasi. Persetujuan pengguna memberi wewenang kepada individu untuk mengizinkan aplikasi mengakses data pribadi mereka. Persetujuan admin memindahkan gerbang persetujuan ke administrator TI, yang mengevaluasi permintaan aplikasi atas nama seluruh organisasi. Baseline keamanan perusahaan modern sering kali menonaktifkan persetujuan pengguna sepenuhnya, sehingga setiap onboarding aplikasi harus melalui alur pra-persetujuan admin yang formal.

Dampak Kebijakan Penyewa terhadap Izin

Kebijakan penyewa tingkat perusahaan dapat secara mendasar mengubah cara aplikasi Anda berperilaku saat runtime. Jika administrator telah menerapkan kebijakan Akses Bersyarat yang ketat, misalnya mewajibkan autentikasi multifaktor (MFA) atau perangkat yang sudah tergabung hybrid dan memenuhi kepatuhan Azure AD, maka aplikasi yang mencoba mengambil token Graph tanpa memenuhi kriteria tersebut akan diblokir. Pengembang harus merancang aplikasi mereka agar mampu menangani kegagalan perolehan token dengan baik dan memberikan langkah perbaikan error yang jelas.

Strategi untuk Alur Persetujuan yang Lancar

Untuk mencegah gesekan bagi pengguna dan hambatan administratif, rencanakan strategi izin Anda sebelum menulis kode. Terapkan pola persetujuan bertahap, di mana aplikasi Anda meminta scope identitas dasar di awal dan hanya meminta izin sumber daya khusus ketika pengguna membuka fitur tertentu. Manfaatkan alur pra-persetujuan otomatis di Microsoft Entra ID untuk mempercepat pengembangan sambil tetap menjaga pengawasan keamanan yang ketat.

Kesalahan Umum dalam Izin Microsoft Graph API

• Mencampuradukkan izin delegasi dan izin aplikasi, serta salah memahami kebutuhan konteks pengguna.
• Meminta izin berlebihan di awal alih-alih menerapkan pendekatan hak akses minimum.
• Tidak memperhitungkan persyaratan persetujuan admin saat menerapkan layanan latar belakang.
• Menganggap perubahan izin di portal Azure akan langsung berlaku tanpa penyegaran token.
• Menggunakan token akses delegasi padahal yang dibutuhkan adalah token client credentials.
• Mengabaikan kebijakan Akses Bersyarat yang memblokir permintaan Graph API saat runtime.
• Lalai memvalidasi klaim scope di dalam kode aplikasi saat runtime.
• Tidak mengaudit izin aplikasi dan service principal yang sudah diberikan dari waktu ke waktu.

Daftar Periksa Izin Microsoft Graph API

Gunakan daftar periksa yang praktis ini untuk memandu tim Anda dalam merancang, menerapkan, dan mengaudit izin Microsoft Graph API secara aman:

Kesimpulan

Memahami izin Microsoft Graph API tidak harus menjadi pekerjaan yang membuat frustrasi. Dengan memahami dengan jelas perbedaan operasional antara izin delegasi (yang memerlukan pengguna yang sudah masuk dan beroperasi dalam batasan pengguna) dan izin aplikasi (yang berjalan tanpa batasan di latar belakang dan memerlukan persetujuan admin), Anda dapat merancang solusi yang aman dan skalabel. Menerapkan prinsip hak akses minimum, menjalankan audit yang ketat, dan memanfaatkan alat tata kelola perusahaan akan menjaga lingkungan Microsoft 365 Anda tetap aman tanpa memperlambat inovasi.

Untuk panduan ahli, strategi nyata, dan pembahasan mendalam tentang pengamanan lingkungan cloud Anda, pastikan untuk mendengarkan ulasan audio lengkap kami pada episode terkait: Microsoft Graph Permissions and Consent Models Explained. Jaga agar izin Anda tetap ketat, kredensial Anda aman, dan selamat ngoding!