Mengapa Autentikasi dan UX Buatan Sendiri Merusak Kepatuhan di Aplikasi M365

By Mirko Peters · 2026-08-11

Selamat datang kembali di blog podcast! Jika Anda pernah menghabiskan berminggu-minggu bergulat dengan alur OAuth kustom, men-debug error kedaluwarsa token yang misterius, atau mencoba mencocokkan M…

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

Titelbild: Why DIY Auth and UX Break Compliance in M365 Apps

Selamat datang kembali di blog podcast! Jika Anda pernah menghabiskan berminggu-minggu untuk bergulat dengan alur OAuth kustom, men-debug error kedaluwarsa token yang misterius, atau berusaha menyamakan tampilan dan nuansa Microsoft dengan CSS Anda sendiri, Anda tidak sendirian. Membangun aplikasi modern yang terintegrasi dengan Microsoft 365 bisa dengan cepat berubah menjadi lubang jebakan rekayasa yang sangat besar. Banyak tim pengembang memulai dengan niat baik—mengira pendekatan buatan sendiri memberi mereka kendali penuh—hanya untuk mendapati diri mereka terkubur di bawah celah audit, ketidakpercayaan pengguna, dan beban keamanan yang berat. Dalam postingan ini, kita akan membahas secara mendalam mengapa membangun lapisan autentikasi dan pengalaman pengguna kustom dari nol adalah jebakan kepatuhan, dan bagaimana Anda dapat memodernisasi tumpukan teknologi Anda.

Diskusi ini merupakan kelanjutan langsung dari episode podcast terbaru kami, Build Consistent M365 Apps with Microsoft Graph Toolkit. Pastikan Anda menonton episode lengkapnya setelah membaca panduan ini untuk mendapatkan penjelasan audio menyeluruh tentang konsep-konsep ini!

Ikhtisar

Sebagian besar aplikasi M365 gagal pada bagian autentikasi, pencarian direktori, dan UX kalender—dan tampilannya pun tidak sesuai dengan identitas merek saat melakukannya. Microsoft Graph Toolkit menyediakan komponen React yang dikelola dan ber-branding Microsoft, yang terhubung ke Graph, menangani token/persetujuan, serta memberikan pengalaman yang tepercaya dan patuh sejak awal—sambil tetap memungkinkan Anda melakukan kustomisasi dengan aman.

Siapa yang Terbantu

Pengembang front-end dan tech lead yang membangun aplikasi terhubung M365
Tim produk yang membutuhkan autentikasi dan fitur direktori yang cepat serta patuh
Pemilik keamanan/kepatuhan yang sudah lelah dengan OAuth kustom yang berisiko dan ketidakselarasan UI

Mengapa Pendekatan Buatan Sendiri Gagal (dan Berisiko bagi Kepatuhan)

Ketika pengembang memutuskan untuk membuat sendiri fitur autentikasi dan pencarian direktori, mereka sering meremehkan kompleksitas ekosistem identitas Microsoft. Solusi buatan sendiri hampir selalu memunculkan tiga kategori risiko utama:

Penyimpangan OAuth: penyambungan MSAL buatan sendiri, penyimpanan token, penyegaran, dan kasus-kasus persetujuan yang gagal secara diam-diam atau membiarkan token keamanan terekspos di local storage.
Ketidaksesuaian UX: font, warna, ikon, dan alur yang tidak sesuai dengan Microsoft, yang menyebabkan hilangnya kepercayaan pengguna dan kebingungan saat muncul perintah login.
Celah audit: layar persetujuan yang tidak konsisten, pencarian orang yang bocor dan melanggar tata kelola data internal, serta skor aksesibilitas yang buruk sehingga gagal memenuhi pemeriksaan kepatuhan perusahaan.

Apa yang Diberikan Graph Toolkit kepada Anda

Alih-alih membangun semuanya dari nol, memanfaatkan pustaka yang terstandarisasi mengubah permainan sepenuhnya. Microsoft Graph Toolkit berfungsi sebagai jembatan antara kode front-end Anda dan Microsoft Graph API, dengan menyediakan:

Komponen React ber-branding Microsoft yang langsung "berfungsi" dengan Graph tanpa memerlukan pembungkus klien API kustom.
Autentikasi & persetujuan bawaan (token, penyegaran, cakupan izin) dengan MSAL di baliknya, dikelola secara aman sesuai praktik terbaik Microsoft.
Caching, throttling, dan status error yang ditangani untuk Anda sejak awal.
Tampilan Fluent UI & aksesibilitas termasuk navigasi keyboard, dukungan pembaca layar, dan tata letak bahasa right-to-left (RTL).
Titik kustomisasi yang aman (props, CSS parts/class) tanpa merusak tanda-tanda kepatuhan yang digunakan pengguna untuk memverifikasi keaslian.

Komponen Inti yang Akan Anda Gunakan Sejak Hari Pertama

Saat mengadopsi toolkit, Anda langsung mendapatkan akses ke pustaka widget UI siap pakai yang lengkap. Beberapa di antaranya sangat penting bagi aplikasi perusahaan mana pun:

Login: Masuk/keluar Microsoft siap pakai, profil, token, dan alur persetujuan—tanpa perlu kode OAuth yang rumit dan kustom.
PeoplePicker: Pencarian direktori Azure AD yang cepat dengan debounce, lengkap dengan avatar dan kemampuan pilih-ganda; menghindari jebakan batas laju (rate-limit) dan paging yang sering dialami implementasi kustom.
Agenda: Acara Outlook ditampilkan dengan isyarat M365 yang familiar (aturan pengulangan, pembaruan, zona waktu) dan caching cerdas untuk performa optimal.

Kapan Menggunakan Toolkit vs. Kode Kustom

Penting untuk mengetahui di mana batasannya. Gunakan toolkit saat Anda membutuhkan sign-in yang aman, pencarian direktori, kalender, tugas, file, presence, dan profil pengguna, yaitu fitur yang harus cepat dan sesuai dengan identitas merek. Sebaliknya, bangun kode kustom jika Anda memerlukan penggabungan data yang sangat khusus, visualisasi yang tidak umum, atau sistem non-Graph sebagai sumber data utama aplikasi Anda.

Mulai Cepat (jalur tanpa drama)

Buat aplikasi Entra ID (Dev/Test/Prod), aktifkan MSAL; berikan izin Graph dengan hak akses minimum.
Pasang dan hubungkan provider di React (provider MSAL + provider Graph Toolkit).
Hapus komponen: <Login />, <PeoplePicker />, <Agenda />.
Atur scope per halaman (misalnya User.Read, Calendars.Read, People.Read) dan verifikasi persyaratan persetujuan.
Terapkan tema dengan aman: gunakan theme token dan CSS part, sambil tetap menjaga pola Microsoft.
Rilis pilot ke kelompok pengguna kecil; kumpulkan masukan tentang UX dan performa; lalu perluas peluncuran.

Daftar Periksa Produksi (keamanan dan keandalan)

Sebelum meluncurkan aplikasi Anda ke produksi, jalankan daftar periksa yang ketat ini untuk memastikan implementasi Anda tetap aman dan andal di bawah beban skala perusahaan:

Scope dengan hak akses minimum; pisahkan secara cermat izin delegasi pengguna dan izin aplikasi.
Penyimpanan rahasia dan sertifikat yang aman (memanfaatkan Azure Key Vault bila sesuai).
Masa berlaku token dan logika retry: verifikasi alur refresh dan terapkan exponential backoff untuk error 429 atau 503.
Conditional Access: uji autentikasi multi-faktor dan kebijakan kepatuhan perangkat terhadap alur toolkit Anda.
Telemetri: catat request ID, metrik latensi, cache hit, dan error Graph API untuk pemantauan yang efektif.
Pemeriksaan aksesibilitas: verifikasi navigasi keyboard, landmark struktural, dan rasio kontras warna.
Tinjauan merek: pastikan gaya Fluent UI dan shell merek kustom Anda tetap konsisten secara visual.

Catatan Performa

Performa bisa menentukan berhasil atau gagalnya adopsi pengguna. Untungnya, komponen-komponen ini dibangun dengan mempertimbangkan optimasi. Komponen tersebut menggunakan lazy data loading dan client caching agar antarmuka pengguna tetap responsif. Hindari panggilan API N+1 dengan mengandalkan komponen daftar bawaan toolkit, dan pastikan Anda melakukan batch pada pencarian pengguna saat memperkaya hasil pencarian atau melakukan paginasi pada daftar panjang.

Kustomisasi Tanpa Mengorbankan Kepercayaan

Pengembang sering khawatir bahwa penggunaan komponen siap pakai membatasi kemampuan mereka untuk memberi merek pada aplikasi. Namun, Anda tetap bisa menyesuaikan pengalaman dengan mudah tanpa mengorbankan keamanan. Gunakan props yang disediakan (seperti rentang tanggal dan filter kueri) alih-alih melakukan fork pada kode. Berikan tema pada aplikasi Anda menggunakan token Fluent dan CSS variable, dan selalu pastikan pola inti Microsoft seperti dialog login dan persetujuan tetap mudah dikenali oleh pengguna.

Jebakan Umum (dan solusinya)

"Berjalan di lokal, gagal di produksi" → Biasanya disebabkan oleh ketidaksesuaian redirect URI atau scope. Periksa kembali pengaturan registrasi aplikasi Azure Entra ID Anda.
Pencarian orang kosong → Scope People.Read atau User.ReadBasic.All tidak ada, atau pengaturan direktori di penyewa Anda terlalu membatasi.
Agenda kosong → Scope Calendars.Read belum disetujui, atau tipe kotak surat yang di-query tidak didukung.
Permintaan sign-in terus berulang → Cookie pihak ketiga diblokir atau kontrol sesi Conditional Access terlalu ketat. Uji di jendela privat dan tinjau kebijakan CA Anda.

Ide KPI untuk Membuktikan Manfaatnya

Untuk membenarkan pergeseran arsitektur ini kepada pimpinan engineering, lacak metrik seperti time-to-first-feature (waktu membangun autentikasi, agenda, dan pemilih orang sebelum versus sesudah mengadopsi toolkit), kegagalan autentikasi dan tiket dukungan help desk per seribu pengguna, waktu hingga halaman interaktif untuk tampilan kalender dan orang, isu aksesibilitas yang ditemukan per rilis, serta pengecualian kepatuhan yang diajukan selama tinjauan keamanan.

Jalur Migrasi (ganti bagian kustom yang berisiko terlebih dahulu)

Ganti penanganan OAuth kustom dengan komponen Login standar.
Ganti pencarian direktori kustom yang tidak dioptimasi dengan komponen PeoplePicker.
Ganti widget kalender kustom dengan komponen Agenda.
Tambahkan fitur pendukung seperti Files, Tasks, dan Presence sesuai kebutuhan roadmap produk Anda.

Kesimpulan

Berhentilah membangun ulang infrastruktur Microsoft dari nol. Microsoft Graph Toolkit memberi Anda blok bangunan M365 yang aman dan sesuai merek, yang sudah dipercaya pengguna serta mudah diterima auditor kepatuhan, sehingga tim engineering Anda bisa fokus pada fitur produk yang benar-benar membedakan bisnis Anda di pasar.

Siap untuk mendalami cara membangun aplikasi Microsoft 365 yang andal dan patuh? Silakan kunjungi podcast dan dengarkan episode lengkapnya: Build Consistent M365 Apps with Microsoft Graph Toolkit!