Mengapa Auth dan UX Buatan Sendiri Merusak Aplikasi M365

By Mirko Peters · 2026-08-11

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

Titelbild: Why DIY Auth and UX Break M365 Apps

Selamat datang kembali di blog ini! Jika Anda pernah menatap layar kosong dan bertanya-tanya mengapa aplikasi Microsoft 365 buatan sendiri tiba-tiba menghasilkan galat autentikasi senyap atau membuat tim kepatuhan keamanan Anda kewalahan, Anda pasti tidak sendirian. Membangun perangkat lunak perusahaan modern sudah cukup sulit tanpa harus menciptakan ulang roda setiap kali Anda perlu mengautentikasi pengguna, mencari di Azure Active Directory, atau menampilkan widget kalender. Namun, tim pengembang di seluruh dunia masih saja terjebak dalam perangkap membangun alur OAuth khusus dan komponen UI buatan sendiri dari nol.

Dalam postingan ini, kita akan membahas secara mendalam mengapa pendekatan buatan sendiri secara rutin merusak aplikasi M365, dengan risiko tersembunyi seperti OAuth drift, hilangnya kepercayaan pengguna, dan celah dalam audit kepatuhan. Yang lebih penting, kita akan mengeksplorasi cara Anda menghindari sakit kepala besar ini dengan memanfaatkan solusi siap pakai yang andal. Mari kita uraikan cara berhenti menulis boilerplate khusus yang berisiko dan mulai merilis front end M365 yang aman dan siap produksi lebih cepat dari sebelumnya.

Ikhtisar

Sebagian besar aplikasi Microsoft 365 pada akhirnya runtuh di tiga titik integrasi kritis: autentikasi, pencarian direktori, dan pengalaman pengguna kalender. Selain merusak fungsionalitas, aplikasi tersebut sering kali juga tampak jauh dari identitas merek Microsoft. Untungnya, ada cara yang lebih baik. Microsoft Graph Toolkit menyediakan komponen React bermerek Microsoft yang terus dipelihara, terhubung langsung ke Microsoft Graph, menangani token dan alur persetujuan yang kompleks secara langsung, serta menghadirkan pengalaman pengguna yang terpercaya dan sepenuhnya patuh—sambil tetap memungkinkan tim Anda menyesuaikannya dengan aman bila diperlukan.

Siapa yang Terbantu

Baik Anda berada di garis depan rekayasa front-end maupun mengelola kepatuhan keamanan perusahaan, memahami pola integrasi modern sangatlah penting. Panduan ini secara khusus dirancang untuk:

Pengembang front-end dan tech lead yang membangun aplikasi web terhubung M365
Tim produk yang membutuhkan fitur autentikasi dan direktori yang cepat dan patuh tanpa membebani siklus sprint mereka
Pemilik keamanan dan kepatuhan yang sudah lelah mengelola implementasi OAuth buatan sendiri yang berisiko serta penyimpangan UI yang tidak terkendali

Mengapa Pendekatan Buatan Sendiri Merusak (dan Membahayakan Kepatuhan)

Semuanya selalu dimulai dengan sederhana. Seorang pengembang berkata, "Kita hanya butuh tombol masuk sederhana dan cara cepat untuk mencari pengguna; menulis pembungkus khusus tidak akan memakan waktu lama." Tiga bulan kemudian, aplikasi Anda dihantui oleh kegagalan halus yang terus berulang:

OAuth drift: Penyambungan MSAL buatan sendiri, penyimpanan token khusus, lingkaran refresh token yang rusak, serta kasus tepi persetujuan yang tidak tertangani yang diam-diam mengunci pengguna dari sistem.
Ketidaksesuaian UX: Font, palet warna, ikon, dan pola interaksi yang bertentangan dengan antarmuka asli Microsoft, sehingga langsung menurunkan kepercayaan pengguna dan menimbulkan kebingungan.
Celah audit: Layar persetujuan yang tidak konsisten, mekanisme pencarian orang yang bocor dan memperlihatkan data tanpa izin, serta aksesibilitas yang buruk sehingga gagal dalam tinjauan keamanan perusahaan.

Apa yang Diberikan Graph Toolkit kepada Anda

Alih-alih bergulat dengan endpoint mentah dan manajemen state khusus, mengadopsi toolkit terstandardisasi mengubah permainan sepenuhnya. Berikut yang Anda dapatkan langsung dari awal:

Komponen React bermerek Microsoft yang terhubung dengan mulus dan "langsung berfungsi" bersama data Microsoft Graph.
Autentikasi dan manajemen persetujuan bawaan (token, siklus refresh, dan cakupan izin yang presisi) dengan MSAL yang beroperasi secara andal di balik layar.
Caching otomatis, throttling cerdas, dan status galat yang terstandardisasi, semuanya ditangani untuk Anda.
Tampilan, nuansa, dan fitur aksesibilitas Fluent UI yang komprehensif (navigasi keyboard penuh, dukungan pembaca layar, dan kesiapan tata letak RTL).
Hook kustomisasi yang aman (melalui props serta CSS parts atau class) yang memungkinkan Anda menata aplikasi tanpa merusak isyarat kepatuhan dan kepercayaan yang penting.

Komponen Inti yang Akan Anda Gunakan Sejak Hari Pertama

Saat Anda mulai mengganti kode tambal sulam dengan komponen terstandardisasi, beberapa blok bangunan esensial akan langsung mengambil alih pekerjaan berat untuk arsitektur Anda:

Login: Pengalaman masuk dan keluar Microsoft yang siap pakai yang mengelola profil pengguna, token, dan alur persetujuan lengkap tanpa memerlukan kode OAuth yang rumit dan khusus.
PeoplePicker: Komponen pencarian direktori Azure AD yang cepat dengan penundaan (debounce), lengkap dengan avatar dan kemampuan pilih banyak, dirancang dengan cermat untuk menghindari pembatasan laju API (rate limiting) dan jebakan paging yang rumit.
Agenda: Acara kalender Outlook yang ditampilkan dengan rapi dengan isyarat visual M365 yang sudah familiar (seperti indikator pengulangan, pembaruan real-time, dan pengelolaan zona waktu), didukung oleh caching lokal yang cerdas.

Kapan Menggunakan Toolkit vs. Kode Kustom

Meski menstandardisasi front end adalah keuntungan besar, Anda tetap perlu tahu di mana harus menarik batas antara komponen platform dan rekayasa kustom:

Toolkit: Gunakan komponen ini setiap kali Anda membutuhkan sign-in aman, pencarian direktori perusahaan, kalender, tugas, file, kehadiran pengguna (user presence), atau pengelolaan profil dengan cepat dan sesuai identitas merek.
Kustom: Bangun kode kustom ketika aplikasi Anda memerlukan penggabungan data (data mashup) yang sangat khusus, visualisasi perusahaan yang bersifat niche, atau ketika sistem non-Graph menjadi sumber kebenaran utama (source of truth).

Panduan Cepat (jalur tanpa drama)

Siap memulai tanpa drama arsitektur? Ikuti jalur sederhana berikut untuk menyiapkan lingkungan Anda:

Buat pendaftaran aplikasi Entra ID di lingkungan Dev, Test, dan Prod Anda, aktifkan dukungan MSAL, dan berikan cakupan (scope) Graph dengan hak akses paling minimal yang diperlukan.
Pasang dan hubungkan penyedia autentikasi di aplikasi React Anda, dengan menggabungkan penyedia MSAL dan penyedia Graph Toolkit.
Letakkan komponen inti ke dalam tampilan Anda: <Login />, <PeoplePicker />, dan <Agenda />.
Atur scope yang tepat per halaman (seperti User.Read, Calendars.Read, dan People.Read) dan verifikasi perilaku persetujuan (consent) pengguna.
Terapkan tema dengan aman melalui token tema dan CSS part yang disetujui, sambil tetap menjaga pola visual inti Microsoft.
Rilis versi pilot ke kelompok pengguna kecil yang terbatas untuk mengumpulkan umpan balik UX dan performa yang penting sebelum memperluas peluncuran.

Daftar Periksa Produksi (keamanan & keandalan)

Sebelum mendorong aplikasi M365 baru Anda ke produksi, pastikan Anda menjalankan daftar periksa keamanan dan keandalan yang penting ini:

Terapkan scope dengan hak akses minimal dan pisahkan secara ketat izin delegasi pengguna dari izin khusus aplikasi (app-only).
Pastikan penyimpanan rahasia atau sertifikat yang aman dengan menggunakan Azure Key Vault.
Verifikasi konfigurasi masa berlaku token, alur refresh, dan penanganan backoff yang tepat untuk kesalahan HTTP 429 dan 503.
Uji kebijakan Conditional Access, termasuk autentikasi multi-faktor dan persyaratan kepatuhan perangkat, terhadap alur kerja toolkit Anda.
Pasang telemetri yang andal untuk mencatat ID permintaan, latensi permintaan, rasio cache hit, dan kesalahan Graph yang masuk.
Lakukan audit aksesibilitas menyeluruh yang mencakup navigasi keyboard, struktur landmark, dan rasio kontras warna yang tepat.
Lakukan tinjauan merek untuk memastikan standar desain Fluent UI dan shell merek perusahaan Anda tetap selaras.

Catatan Performa

Pengguna perusahaan tidak punya kesabaran terhadap perangkat lunak yang lambat. Agar aplikasi Anda terasa sangat cepat:

Manfaatkan sepenuhnya komponen yang menggunakan lazy loading data dan caching sisi klien yang cerdas agar antarmuka pengguna tetap responsif.
Hindari panggilan API N+1 yang mahal dengan mengutamakan daftar toolkit native dan komponen multi-item bila memungkinkan.
Gabungkan (batch) pencarian pengguna saat memperkaya hasil pencarian, dan selalu lakukan paging pada daftar perusahaan yang panjang dengan benar.

Kustomisasi Tanpa Mengorbankan Kepercayaan

Kustomisasi sangat penting untuk menyesuaikan identitas korporat Anda, tetapi kustomisasi berlebihan menghancurkan kepercayaan pengguna. Perhatikan batasan berikut:

Gunakan props komponen standar (seperti rentang tanggal dan filter kueri) daripada membuat fork dan mengubah kode sumber inti.
Berikan tema pada aplikasi Anda menggunakan token desain Fluent dan CSS variable, sambil memastikan pola Microsoft yang familiar tetap mudah dikenali.
Perluas fungsionalitas secara bersih melalui event hook bawaan (seperti onSelect atau onSignIn) untuk memicu alur kerja hilir Anda dengan aman.

Jebakan Umum (dan solusinya)

Meskipun alatnya bagus, pengembang kadang tetap menemui kendala. Berikut jebakan paling umum dan cara memperbaikinya:

"Berfungsi di lokal, gagal di produksi": Biasanya disebabkan oleh ketidaksesuaian redirect URI atau scope. Periksa kembali pengaturan pendaftaran aplikasi di portal Azure Anda.
Pencarian orang tampak kosong: Biasanya disebabkan oleh tidak adanya izin People.Read atau User.ReadBasic.All, atau pembatasan visibilitas direktori yang ketat.
Widget agenda kosong: Periksa apakah izin Calendars.Read sudah diberikan secara eksplisit, atau apakah jenis kotak surat pengguna tidak didukung.
Permintaan masuk yang tidak berhenti: Sering dipicu oleh pemblokiran cookie pihak ketiga atau kontrol sesi Conditional Access yang ketat. Uji di jendela penjelajahan pribadi dan tinjau kebijakan CA Anda.

Ide KPI untuk Membuktikan Keberhasilan

Jika Anda perlu meyakinkan pimpinan atau pemangku kepentingan bahwa beralih ke toolkit standar sepadan dengan usahanya, pantau indikator kinerja utama berikut:

Waktu hingga fitur pertama untuk membangun kemampuan inti seperti autentikasi, agenda, dan pemilih, sebelum dan sesudah menerapkan toolkit.
Total kegagalan autentikasi dan tiket dukungan help desk terkait per seribu pengguna aktif.
Waktu muat halaman hingga interaktif untuk tampilan berat seperti Agenda dan PeoplePicker.
Jumlah cacat atau pelanggaran aksesibilitas yang ditemukan per siklus rilis.
Pengecualian kepatuhan dan keamanan yang diajukan selama tinjauan desain formal, dengan target yang jelas yaitu nol.

Jalur Migrasi (ganti bagian kustom yang berisiko terlebih dahulu)

Anda tidak perlu merefaktor seluruh aplikasi dalam semalam. Lakukan pendekatan bertahap dengan mengganti kode kustom yang paling berisiko terlebih dahulu:

Ganti implementasi OAuth kustom Anda yang rapuh dengan komponen Login standar.
Ganti logika pencarian direktori kustom yang terbatas laju dengan komponen PeoplePicker yang andal.
Tingkatkan widget kalender manual Anda untuk menggunakan komponen Agenda yang sudah jadi.
Tambahkan fitur sekunder seperti Files, Tasks, dan indikator Presence sesuai kebutuhan peta jalan produk Anda.

Poin Penting

Berhentilah membuang waktu berharga tim engineering untuk membangun ulang Microsoft dari nol. Memanfaatkan alat seperti Microsoft Graph Toolkit memberi Anda blok bangunan M365 yang aman, sesuai dengan identitas visual Microsoft, dan secara alami dipercaya oleh pengguna perusahaan serta diterima dengan baik oleh auditor keamanan. Hal ini memungkinkan tim pengembang Anda fokus pada fitur produk yang unik dan logika bisnis yang benar-benar membedakan Anda dari kompetitor.

Untuk memahami topik ini lebih dalam dan mendengar strategi implementasi praktis dari lapangan, dengarkan episode podcast pendamping kami: Build Consistent M365 Apps with Microsoft Graph Toolkit.