Menyingkap OAuth 2.0 di Microsoft Graph: Izin Delegasi vs. Izin Aplikasi

By Mirko Peters · 2026-08-11 · Updated 2026-08-28

Selamat datang kembali di blog! Jika Anda sudah mendalami otomasi Microsoft 365, kemungkinan besar Anda pernah menemui batasan yang dibangun oleh konektor bawaan dan keterbatasan skrip tradisional. Mengelola kompleksitas autentikasi bisa menjadi tantangan saat mengotomatisasi M365, terutama ketika Anda perlu menyeimbangkan keamanan yang kokoh dengan fungsionalitas yang mulus. Baik Anda sedang memb

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

Selamat datang kembali di blog ini! Jika Anda sudah mendalami otomatisasi Microsoft 365, kemungkinan besar Anda pernah menemui batasan yang ditetapkan oleh konektor bawaan dan skrip tradisional. Mengelola autentikasi bisa menjadi rumit saat mengotomatisasi M365, terutama ketika Anda perlu menyeimbangkan keamanan yang kokoh dengan fungsionalitas yang mulus. Baik Anda sedang membangun aplikasi enterprise kustom maupun menyiapkan proses otomatis di latar belakang, memahami model autentikasi dengan baik sangatlah penting. Artikel ini menguraikan token, scope, dan alur persetujuan (consent) untuk membantu Anda memilih model yang tepat, baik untuk tugas yang berpusat pada pengguna maupun tugas tanpa pengawasan di latar belakang. Mari langsung kita bahas dan pahami cara OAuth 2.0 menjalankan Microsoft Graph API.

Pengantar Autentikasi Microsoft Graph

Microsoft Graph adalah gerbang terpadu ke seluruh ekosistem Microsoft 365. Alih-alih berinteraksi dengan API terpisah dan terfragmentasi untuk Exchange, SharePoint, Teams, dan Azure Active Directory (kini Microsoft Entra ID), pengembang dan administrator TI dapat mengakses semua layanan ini melalui satu endpoint. Namun, karena Graph mengendalikan akses ke data perusahaan yang sensitif, pengamanan gerbang ini memerlukan kerangka autentikasi yang ketat. Memahami bagaimana identitas, token akses, dan izin saling berkaitan adalah langkah pertama untuk membangun otomasi yang andal dan aman, yang tidak mudah gagal di bawah tekanan atau memicu peringatan keamanan.

Memahami OAuth 2.0 dalam Konteks Microsoft 365

Pada intinya, Microsoft Graph mengandalkan protokol OAuth 2.0 untuk otorisasi. Ketika aplikasi atau skrip Anda ingin berkomunikasi dengan Graph, aplikasi tersebut tidak bisa begitu saja mengirimkan kredensial mentah melalui jaringan. Sebaliknya, aplikasi harus meminta token akses dari platform identitas Microsoft (Entra ID). Token akses ini berfungsi sebagai paspor digital yang aman. Token ini memberi tahu Microsoft Graph siapa yang membuat permintaan, aplikasi apa yang digunakan, dan—yang paling penting—izin spesifik (scope) apa yang telah diberikan kepada token tersebut. Tanpa token yang valid, Graph akan langsung menolak permintaan dengan galat unauthorized standar.

Izin Delegasi: Kapan Berjalan sebagai Pengguna

Memilih model izin yang tepat sepenuhnya bergantung pada sifat beban kerja Anda. Izin delegasi dirancang untuk aplikasi yang berjalan dengan dukungan pengguna yang sedang masuk. Ketika sebuah aplikasi menggunakan izin delegasi, aplikasi tersebut bertindak atas nama pengguna yang sedang aktif masuk. Jika seorang pengguna menjalankan skrip untuk membaca kalender miliknya sendiri atau memperbarui foto profilnya, Graph mengevaluasi permintaan berdasarkan bukan hanya apa yang diizinkan untuk dilakukan aplikasi, tetapi juga apa yang boleh diakses oleh pengguna tersebut. Jika pengguna tidak memiliki izin untuk melihat kotak surat tertentu, token delegasi juga tidak akan memberikannya. Model ini ideal untuk aplikasi yang berhadapan langsung dengan pengguna, alat interaktif, dan skrip produktivitas pribadi.

Izin Aplikasi: Menggerakkan Tugas Latar Belakang Tanpa Pengawasan

Sebaliknya, bagaimana jika Anda perlu menjalankan skrip atau layanan pada tengah malam tanpa ada pengguna yang duduk di depan keyboard? Untuk tugas latar belakang tanpa pengawasan, layanan daemon, dan alat pelaporan lintas penyewa, Anda memerlukan izin aplikasi. Dalam model ini, aplikasi beroperasi secara independen dari konteks pengguna mana pun—aplikasi berjalan dengan identitasnya sendiri. Karena tidak ada pengguna manusia yang masuk dan memberikan persetujuan secara interaktif, izin aplikasi memerlukan otorisasi awal yang eksplisit dari administrator penyewa. Setelah diberikan, aplikasi dapat mengakses data di seluruh organisasi, sehingga model ini sangat kuat untuk otomasi administratif, skrip onboarding, dan pemantauan kepatuhan, tetapi juga menuntut pengawasan keamanan yang ketat.

Menavigasi Scope, Token, dan Alur Persetujuan

Kosakata autentikasi dan otorisasi kadang terasa membingungkan, tetapi dengan memecah alurnya, prosesnya menjadi lebih jelas. Scope adalah izin spesifik yang diminta aplikasi Anda, misalnya User.Read.All atau Mail.Read. Saat pengguna atau admin mengotorisasi aplikasi, mereka sebenarnya sedang meninjau dan menyetujui scope tersebut. Setelah disetujui, platform identitas menerbitkan JSON Web Token (JWT). Kode Anda menyertakan token ini di header HTTP Authorization untuk setiap permintaan yang dikirim ke Microsoft Graph. Mengelola persetujuan (consent) dengan benar memastikan aplikasi Anda dapat memperoleh token ini dengan lancar tanpa terhambat kendala yang tidak terduga.

Menghindari Jebakan Persetujuan Admin

Salah satu titik gesekan paling umum yang dihadapi developer dan administrator adalah terjebak menunggu persetujuan administratif. Ketika aplikasi meminta scope aplikasi dengan hak istimewa tinggi atau scope delegated yang sensitif, Microsoft Entra ID mungkin mengharuskan administrator menyetujui aplikasi tersebut sebelum token apa pun dapat diterbitkan. Jika pipeline deployment Anda mengasumsikan pengguna dapat memberikan persetujuan sendiri, lalu tiba-tiba diblokir oleh kebijakan penyewa, otomatisasi Anda akan berhenti total. Untuk menghindari jebakan persetujuan admin ini, selalu petakan izin yang dibutuhkan sejak awal, dokumentasikan justifikasi bisnisnya, dan koordinasikan dengan administrator global atau administrator aplikasi Anda untuk mengonfigurasi persetujuan di seluruh penyewa bila diperlukan.

Kesalahan Umum dan Cara Mengatasinya

Bahkan developer berpengalaman pun kadang menghadapi kendala otorisasi yang menjengkelkan saat bekerja dengan Microsoft Graph. Mari kita lihat beberapa masalah umum dan cara menyelesaikannya:

• Berfungsi di saya, gagal di orang lain: Biasanya disebabkan oleh persetujuan yang belum ada atau scope yang keliru. Solusi: Dokumentasikan scope yang dibutuhkan dengan jelas dan konfigurasikan persetujuan admin di seluruh penyewa bila sesuai.
• Mengambil payload raksasa secara berlebihan: Menarik seluruh daftar pengguna tanpa filter menyebabkan timeout dan throttling. Solusi: Gunakan $select, $top, paginasi, dan kueri delta.
• Loop 401/403 tanpa henti: Disebabkan oleh token yang kedaluwarsa atau penggunaan izin delegated untuk tugas tanpa pengguna. Solusi: Terapkan penyegaran token yang andal dan beralih ke izin aplikasi untuk tugas latar belakang.
• Mencapai batas laju: Menerima respons 429 berarti Anda mengirim permintaan terlalu cepat. Solusi: Terapkan exponential backoff, patuhi header Retry-After, dan gabungkan operasi dalam batch.
• Penyebaran secret: Menanamkan client secret secara langsung (hardcode) di dalam skrip adalah risiko keamanan yang sangat besar. Solusi: Manfaatkan Azure Key Vault, managed identity, atau variabel lingkungan yang aman.

Praktik Terbaik Keamanan dan Tata Kelola

Ketika Anda membuka pintu ke penyewa Microsoft 365 melalui API, keamanan harus menjadi prioritas utama. Patuhi prinsip hak akses minimal: Anda hanya boleh meminta scope minimum yang benar-benar dibutuhkan agar aplikasi berfungsi, dan jangan pernah meminta Directory.AccessAsUser.All hanya untuk membaca nama tampilan pengguna. Pelihara catatan persetujuan (consent ledger) yang jelas tentang aplikasi mana yang memiliki akses ke penyewa Anda, pisahkan sepenuhnya registrasi aplikasi untuk pengembangan, pengujian, dan produksi, serta tetapkan jadwal ketat untuk merotasi client secret dan sertifikat.

Kueri Nyata Pertama Anda (Contoh)

Setelah model autentikasi Anda beres, Anda dapat mulai menjalankan kueri ke Graph API. Berikut beberapa contoh praktis yang dapat Anda sesuaikan:

• Karyawan baru sejak tanggal tertentu:
  GET /users?$filter=createdDateTime ge 2025-10-01T00:00:00Z&$select=id,displayName,mail,department
• Rapat saya berikutnya:
  GET /me/events?$top=10&$select=subject,start,end,organizer,webLink
• Anggota tim dari sebuah grup:
  GET /groups/{group-id}/members?$select=id,displayName,mail
• Pengguna yang berubah (delta):
  GET /users/delta?$select=id,displayName,mail

Alat yang Direkomendasikan

Memanfaatkan alat yang tepat membuat penyusunan dan debugging kueri Microsoft Graph jauh lebih mudah. Graph Explorer adalah area uji coba berbasis web yang sangat berharga untuk menguji endpoint dan memeriksa petunjuk persetujuan. Untuk menulis kode, Microsoft Graph SDK (.NET, JavaScript, Python) menyembunyikan sebagian besar detail HTTP di baliknya. Ekstensi Postman atau REST Client di IDE Anda sangat membantu mengelola koleksi dan environment, sementara Power Automate, Logic Apps, dan PowerShell menangani otomatisasi alur kerja visual dan operasional dengan sangat baik.

Pertanyaan Umum

Delegated vs. Application: bagaimana cara memilihnya?

Tugas yang berpusat pada pengguna paling cocok dipetakan ke izin Delegated. Pekerjaan tanpa pengawasan, daemon latar belakang, dan tugas administratif yang luas memerlukan izin Application yang disertai persetujuan admin yang tepat.

Bagaimana cara menghindari throttling?

Gunakan $select untuk membatasi ukuran payload, terapkan pagination dan delta query, gabungkan permintaan dalam batch jika memungkinkan, dan selalu bangun skrip Anda agar dapat menangani kode status 429 dengan baik menggunakan logika retry.

Bisakah saya menggunakan Graph tanpa coding?

Bisa! Anda dapat membuat prototipe endpoint di Graph Explorer dan mengorkestrasi alur kerja menggunakan Power Automate. Untuk logika yang kompleks, beralihlah menggunakan SDK resmi atau skrip PowerShell.

Apakah Graph cukup aman untuk laporan kepatuhan?

Tentu saja. Jika diterapkan dengan prinsip hak akses minimum, pencatatan log terpusat, alur persetujuan yang diaudit, dan pengelolaan rahasia yang aman, Microsoft Graph memenuhi standar kepatuhan perusahaan yang ketat.

Kesimpulan

Menguasai autentikasi dalam Microsoft Graph adalah kunci utama bagi administrator, arsitek, atau pengembang mana pun yang ingin benar-benar memanfaatkan kekuatan Microsoft 365. Dengan memahami perbedaan krusial antara izin delegated dan application, mengelola scope dan token secara cermat, serta menerapkan tata kelola keamanan yang ketat, Anda dapat membangun otomasi yang sekaligus andal dan aman. Untuk mendalami topik ini lebih jauh, menjelajahi contoh kode, dan mempelajari strategi lanjutan untuk penanganan error dan throttling, pastikan Anda juga menyimak episode podcast terkait: Automate Microsoft 365 with Microsoft Graph API. Selamat berotomasi!