Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Pelajari cara menggunakan platform identitas Microsoft dan ID Microsoft Entra untuk meningkatkan ketahanan aplikasi daemon. Temukan informasi tentang proses latar belakang, layanan, server ke aplikasi server, dan aplikasi tanpa pengguna.
Lihat, Apa itu platform identitas Microsoft?
Diagram berikut mengilustrasikan aplikasi daemon yang melakukan panggilan ke platform identitas Microsoft.
Identitas terkelola untuk sumber daya Azure
Jika Anda membangun aplikasi daemon di Microsoft Azure, gunakan identitas terkelola untuk sumber daya Azure, yang menangani rahasia dan kredensial. Fitur ini meningkatkan ketahanan dengan menangani kedaluwarsa sertifikat, rotasi, atau kepercayaan.
Lihat, Apa itu identitas terkelola untuk sumber daya Azure?
Identitas terkelola menggunakan token akses berumur panjang dan informasi dari platform identitas Microsoft untuk memperoleh token baru sebelum token kedaluwarsa. Aplikasi Anda berjalan saat memperoleh token baru.
Identitas terkelola menggunakan titik akhir regional, yang membantu mencegah kegagalan di luar wilayah dengan mengonsolidasikan dependensi layanan. Titik akhir regional membantu menjaga lalu lintas di area geografis. Misalnya, jika sumber daya Azure Anda berada di WestUS2, semua lalu lintas tetap berada di WestUS2.
Pustaka Autentikasi Microsoft
Jika Anda mengembangkan aplikasi daemon dan tidak menggunakan identitas terkelola, gunakan Microsoft Authentication Library (MSAL) untuk autentikasi dan otorisasi. MSAL memudahkan proses penyediaan kredensial klien. Misalnya, aplikasi Anda tidak perlu membuat dan menandatangani pernyataan token web JSON dengan kredensial berbasis sertifikat.
Lihat, Gambaran Umum Microsoft Authentication Library (MSAL)
Microsoft.Identity.Web untuk pengembang .NET
Jika Anda mengembangkan aplikasi daemon di ASP.NET Core, gunakan pustaka Microsoft.Identity.Web untuk memudahkan otorisasi. Ini termasuk strategi cache token terdistribusi untuk aplikasi terdistribusi yang berjalan di beberapa wilayah.
Pelajari lebih lanjut:
Cache dan simpan token
Jika Anda tidak menggunakan MSAL untuk autentikasi dan otorisasi, ada praktik terbaik untuk caching dan penyimpanan token. MSAL menerapkan dan mengikuti praktik terbaik ini.
Aplikasi memperoleh token dari Penyedia Identitas (IdP) untuk mengotorisasi aplikasi untuk memanggil API yang dilindungi. Saat aplikasi Anda menerima token, respons yang berisi token tersebut berisi properti expires\_in yang memberi tahu aplikasi berapa lama token tersebut harus dicache dan digunakan ulang. Pastikan aplikasi menggunakan expires\_in properti untuk menentukan masa pakai token. Konfirmasikan aplikasi tidak mencoba mendekode token akses API. Menggunakan token yang di-cache mencegah lalu lintas yang tidak perlu antara aplikasi dan platform identitas Microsoft. Pengguna masuk ke aplikasi Anda untuk masa pakai token.
Sistem autentikasi cadangan ID Microsoft Entra memberikan ketahanan terhadap aplikasi yang menggunakan protokol dan alur yang didukung. Untuk informasi selengkapnya tentang persyaratan aplikasi untuk mendapatkan manfaat dari autentikasi cadangan, lihat persyaratan aplikasi untuk sistem autentikasi cadangan.
Kode kesalahan HTTP 429 dan 5xx
Gunakan bagian berikut untuk mempelajari tentang kode kesalahan HTTP 429 dan 5xx
HTTP 429
Ada kesalahan HTTP yang memengaruhi ketahanan. Jika aplikasi Anda menerima kode kesalahan HTTP 429, Terlalu Banyak Permintaan, platform identitas Microsoft membatasi permintaan Anda, yang mencegah aplikasi Anda menerima token. Pastikan aplikasi Anda tidak mencoba memperoleh token hingga waktu di bidang respons Retry-After berakhir. Kesalahan 429 sering menunjukkan aplikasi tidak menyimpan cache dan menggunakan kembali token dengan benar.
HTTP 5xx
Jika aplikasi menerima kode kesalahan HTTP 5x, aplikasi tidak boleh memasukkan perulangan coba lagi yang cepat. Pastikan aplikasi menunggu hingga bidang Coba Lagi-Setelah kedaluwarsa. Apabila respons tidak menyediakan header Retry-After, gunakan penundaan eksponensial dengan percobaan ulang pertama, setidaknya 5 detik setelah respons.
Ketika waktu permintaan habis, konfirmasikan bahwa aplikasi tidak segera mencoba kembali. Gunakan metode "exponential back-off retry" yang telah disebutkan sebelumnya.