Mengotorisasi aplikasi, sumber daya, dan beban kerja dengan ID Microsoft Entra

Dalam artikel ini, kami membahas otorisasi ketika seseorang berinteraksi dengan manusia dan mengarahkan aplikasi, ketika Application Programming Interfaces (API) bertindak untuk pengguna. Kami juga membahas kapan aplikasi atau layanan bekerja secara independen. Ini adalah yang keempat dalam serangkaian artikel tentang bagaimana pengembang perangkat lunak independen (ISV) dapat membangun dan mengoptimalkan aplikasi mereka untuk ID Microsoft Entra. Dalam seri ini, Anda dapat mempelajari lebih lanjut tentang topik-topik ini:

• ID Microsoft Entra untuk Pengembang Perangkat Lunak Independen menjelaskan cara menggunakan layanan manajemen identitas dan akses berbasis cloud ini untuk memungkinkan karyawan mengakses sumber daya dengan aplikasi Anda.
• Membuat aplikasi di ekosistem ID Microsoft Entra menjelaskan cara menggunakan pusat admin Microsoft Entra atau Microsoft Graph API untuk mendaftarkan aplikasi di penyewa ID Microsoft Entra.
• Mengautentikasi aplikasi dan pengguna menjelaskan cara aplikasi menggunakan ID Microsoft Entra untuk mengautentikasi pengguna dan aplikasi.
• Menyesuaikan token membantu Anda membangun keamanan ke dalam aplikasi dengan token ID dan token akses dari ID Microsoft Entra. Ini menjelaskan informasi yang dapat Anda terima di token ID Microsoft Entra dan bagaimana Anda dapat menyesuaikannya.

Otorisasi dalam aplikasi

Di bagian ini, kami membahas skenario di mana seseorang berinteraksi dengan manusia dan mengarahkan aplikasi. Bagian Otorisasi di sumber daya (API) menjelaskan bagaimana API melakukan otorisasi saat pengguna memerlukan otorisasi untuk mengakses sumber daya, tetapi ID Microsoft Entra tidak melakukan otorisasi akhir. Bagian Otorisasi dalam beban kerja mencakup skenario di mana aplikasi atau layanan bekerja secara independen.

Aplikasi memerlukan otorisasi berikut ketika mereka perlu mengakses sumber daya untuk pengguna.

• Aplikasi harus memiliki otorisasi untuk mengakses operasi tertentu dalam sumber daya tertentu untuk pengguna saat ini.
• Pengguna harus memiliki otorisasi untuk mengakses sumber daya dalam kondisi saat ini.
• Pengguna harus memiliki otorisasi untuk mengakses sumber daya.

Proses otorisasi dimulai dengan aplikasi yang menggunakan OAuth 2.0 untuk meminta token akses dari ID Microsoft Entra untuk mengakses operasi tertentu dalam sumber daya tertentu bagi pengguna. Dalam akses yang didelegasikan, aplikasi bertindak sebagai delegasi untuk pengguna.

Untuk pengembang, sumber daya dapat menjadi API seperti Microsoft Graph, Azure Storage, atau API mereka sendiri. Namun, sebagian besar API memiliki berbagai operasi seperti membaca dan menulis. Saat aplikasi hanya membaca dari API, aplikasi hanya boleh memiliki otorisasi untuk operasi membaca. Pendekatan ini melindungi aplikasi dari penyusupan dan penggunaan untuk lebih banyak akses daripada yang dimaksudkan pengembang. Pengembang mengikuti prinsip hak istimewa paling sedikit ketika aplikasi mereka hanya mengotorisasi untuk operasi yang diperlukan.

Untuk menunjuk operasi tertentu mana dalam API tertentu yang diperlukan aplikasi, pengembang menggunakan parameter cakupan permintaan OAuth 2.0. Perancang API menerbitkan cakupan yang dapat diminta aplikasi sebagai bagian dari pendaftaran aplikasi API. Misalnya, cakupan Microsoft layanan Power BI menyertakan yang berikut ini.

cakupan layanan Power BI	Operasional
https://analysis.windows.net/powerbi/api/Capacity.Read.All	Aplikasi ini dapat menampilkan semua kapasitas Power BI Premium dan Power BI Embedded yang dapat diakses pengguna yang masuk.
https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All	Aplikasi ini dapat menampilkan dan mengedit semua kapasitas Power BI Premium dan Power BI Embedded yang dapat diakses pengguna yang masuk.

Jika aplikasi hanya membaca kapasitas, aplikasi akan meminta https://analysis.windows.net/powerbi/api/Capacity.Read.All cakupan. Jika aplikasi mengedit kapasitas, aplikasi akan meminta https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All cakupan.

Cakupan berisi identitas API dan identitas operasi. https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All Dalam cakupan, API adalah https://analysis.windows.net/powerbi/api. Operasinya adalah Capacity.ReadWrite.All. Mengingat jangkauan luas dan popularitas Microsoft Graph API, pengembang dapat meminta cakupan untuk Microsoft Graph tanpa komponen API cakupan. Misalnya, Microsoft Graph menentukan cakupan https://graph.microsoft.com/Files.Read aplikasi tersebut dapat meminta Files.Read alih-alih menggunakan nama cakupan lengkap.

Untuk menyelesaikan otorisasi pertama, aplikasi harus memiliki otorisasi untuk mengakses operasi tertentu dalam sumber daya tertentu untuk pengguna saat ini, ID Microsoft Entra harus terlebih dahulu mengautentikasi pengguna saat ini. Akses menyeluruh (SSO) dapat memenuhi autentikasi ini, atau mungkin memerlukan interaksi pengguna baru.

Setelah MICROSOFT Entra ID menentukan pengguna, id tersebut memeriksa apakah pengguna mengizinkan aplikasi untuk cakupan yang diminta. Proses ini disebut memberikan persetujuan. Jika pengguna memberikan persetujuan, proses otorisasi dapat dilanjutkan. Persetujuan admin memungkinkan pengguna admin untuk menyetujui diri mereka sendiri dan untuk seluruh organisasi. ID Microsoft Entra memeriksa apakah aplikasi memiliki persetujuan admin untuk cakupan. Jika diberikan, proses otorisasi berlanjut.

Selama desain cakupan, perancang API dapat menunjuk cakupan yang hanya dapat diijinkan oleh admin. Cakupan yang memerlukan persetujuan admin mewakili operasi yang dianggap perancang API lebih sensitif, kuat, atau cukup berimplikasi luas sehingga pengguna nonadmin tidak boleh memiliki wewenang untuk diberikan ke aplikasi.

Meskipun desainer API memiliki pernyataan pertama di mana cakupan mereka memerlukan persetujuan admin, mereka tidak memiliki kata akhir. Ketika perancang API menunjuk bahwa cakupan memerlukan persetujuan admin, maka cakupan selalu memerlukan persetujuan admin. Untuk cakupan yang tidak ditetapkan perancang API sebagai memerlukan persetujuan admin, admin penyewa dapat memerlukan persetujuan admin atau persetujuan peningkatan berbasis risiko dapat menentukan persyaratan persetujuan admin. Pengembang tidak dapat memprediksi apakah permintaan token memerlukan persetujuan admin. Namun, batasan ini tidak berdampak pada kode yang diperlukan. Penolakan persetujuan hanyalah salah satu dari banyak alasan untuk penolakan permintaan token. Aplikasi harus selalu menangani dengan baik tidak menerima token.

Jika pengguna atau admin belum memberikan persetujuan, pengguna akan melihat permintaan persetujuan seperti yang ditunjukkan dalam contoh berikut.

Permintaan persetujuan pengguna admin dapat memungkinkan mereka memilih Persetujuan atas nama organisasi Anda untuk memberikan persetujuan bagi semua pengguna di penyewa seperti yang ditunjukkan dalam contoh berikut.

Aplikasi mengontrol waktu permintaan persetujuan pengguna. ID Microsoft Entra mendukung persetujuan statis: saat aplikasi menggunakan .default cakupan, aplikasi meminta semua izin yang dideklarasikan dalam pendaftaran aplikasi. Dengan persetujuan statis, aplikasi Anda meminta terlebih dahulu semua izin yang mungkin diperlukan.

Persetujuan statis dapat mencegah pengguna dan admin menyetujui permintaan akses aplikasi Anda. Praktik terbaik untuk proses permintaan persetujuan adalah meminta izin yang diperlukan secara dinamis untuk fungsionalitas garis besar dalam aplikasi Anda saat pengaktifan aplikasi dan meminta lebih banyak cakupan, saat diperlukan. Meminta lebih banyak cakupan secara bertahap karena aplikasi melakukan operasi yang memerlukan cakupan tersebut. Pendekatan ini memberi pengguna pemahaman yang lebih baik tentang izin lain yang berkorelasi dengan waktu fungsionalitas. Untuk setiap token akses API, ID Microsoft Entra menyertakan semua cakupan yang sebelumnya diberikan ke aplikasi dan bukan hanya cakupan dalam permintaan.

Misalnya, aplikasi dapat meminta https://graph.microsoft.com/user.read untuk masuk ke pengguna dan mengakses profil pengguna saat aplikasi dimulai. Nantinya, pengguna memilih Simpan ke OneDrive dan aplikasi meminta https://graph.microsoft.com/files.readwrite untuk menulis file ke OneDrive pengguna. Karena pengguna melihat mengapa aplikasi meminta untuk menulis ke OneDrive mereka, pengguna memberikan izin dan aplikasi menyimpan file ke OneDrive pengguna. Pengguna kemudian menutup aplikasi. Lain kali aplikasi dimulai, aplikasi meminta https://graph.microsoft.com/user.read. MICROSOFT Entra ID mengembalikan token akses dengan https://graph.microsoft.com/user.read cakupan dan https://graph.microsoft.com/files.readwrite . Permintaan token untuk https://graph.microsoft.com/files.readwrite cakupan tidak memerlukan persetujuan seperti yang diberikan pengguna. Penembolokan token di Microsoft Authentication Libraries (MSAL) secara otomatis menangani token penembolokan berdasarkan izin yang diberikan. Dalam contoh ini, setelah aplikasi dimulai ulang, memanggil MSAL untuk memperoleh token dengan https://graph.microsoft.com/files.readwrite cakupan mengembalikan token yang di-cache dari permintaan awal aplikasi untuk https://graph.microsoft.com/user.read cakupan. Panggilan lain ke ID Microsoft Entra tidak perlu.

Persetujuan dinamis dan inkremental tidak memerlukan izin yang dinyatakan selama pendaftaran aplikasi. Namun, kami sangat menyarankan agar aplikasi menyatakan izin apa pun yang mungkin diperlukan aplikasi dalam pendaftaran aplikasi untuk mendukung persetujuan statis. Admin dapat memberikan persetujuan admin di pusat admin Microsoft Entra, menggunakan Microsoft Graph PowerShell, atau dengan Microsoft Graph API.

Untuk memberikan persetujuan admin untuk aplikasi, pusat admin Microsoft Entra menggunakan persetujuan statis dengan meminta persetujuan dengan .default cakupan untuk aplikasi. Admin tidak dapat memberikan persetujuan admin di pusat admin Microsoft Entra ke aplikasi yang memerlukan izin jika pengembang tidak mendeklarasikannya dalam pendaftaran aplikasi.

Pelanggan ID Microsoft Entra dapat menggunakan kebijakan Akses Bersyar untuk melindungi sumber daya (API) dan aplikasi berbasis browser. Secara default, admin tidak dapat menerapkan kebijakan Akses Bersyar ke autentikasi aplikasi asli. Admin penyewa dapat menargetkan Semua sumber daya (sebelumnya 'Semua aplikasi cloud') atau menggunakan atribut keamanan kustom untuk menargetkan aplikasi asli dengan kebijakan Akses Bersyar . Bahkan jika tidak ditargetkan, penegakan kebijakan tidak menyertakan beberapa aplikasi yang mengakses Microsoft Graph atau Azure AD Graph.

Aplikasi biasanya tidak memerlukan kode khusus untuk Akses Bersyarat kecuali skenario berikut berlaku.

• Aplikasi yang melakukan alur atas nama
• Aplikasi yang mengakses beberapa layanan atau sumber daya
• Aplikasi satu halaman yang menggunakan MSAL.js
• Aplikasi web yang memanggil sumber daya

Jika aplikasi Anda menerapkan salah satu skenario ini, tinjau Panduan pengembang untuk Microsoft Entra Conditional Access.

Penyewa MICROSOFT Entra ID gratis tidak dapat menggunakan Akses Bersyar (lihat persyaratan lisensi. Penyewa produksi perusahaan Anda mungkin memiliki lisensi yang diperlukan. Evaluasi kondisi ini sebelum Anda menggunakan penyewa produksi untuk pengujian. Ada panduan untuk membuat penyewa pengujian.

Secara default, kebijakan Akses Bersyar berlaku untuk aplikasi dan sumber daya yang diakses aplikasi di tingkat aplikasi. Admin TI dapat menerapkan kebijakan tingkat aplikasi ke aplikasi apa pun tanpa partisipasi pengembang. Beberapa aplikasi dan skenario membutuhkan lebih banyak granularitas. Misalnya, aplikasi keuangan mungkin memerlukan autentikasi multifaktor untuk penggunaan umum. Namun, transaksi melalui jumlah yang ditunjuk dapat memerlukan perangkat terkelola. Pengembang dapat memungkinkan admin TI untuk menetapkan kebijakan Akses Bersyar ke area aplikasi yang berbeda dengan menerapkan konteks autentikasi Akses Bersyar. Panduan pengembang untuk konteks autentikasi Akses Bersyar adalah referensi yang baik untuk fitur-fitur ini.

Secara default, ID Microsoft Entra mengeluarkan token akses yang valid untuk waktu yang ditetapkan. Aplikasi tidak boleh mengasumsikan panjang seumur hidup. Mereka harus menggunakan expires_in parameter yang dikembalikan ID Microsoft Entra dengan token akses. MSAL secara otomatis menangani skenario ini. Selama masa pakai token akses, pengguna memiliki otorisasi untuk mengakses sumber daya dalam kondisi pada saat otorisasi.

Jeda antara kapan kondisi berubah dan kapan pemberlakuan perubahan kebijakan terjadi mungkin menyangkut admin dan pengguna. Misalnya, ketika pengguna kehilangan perangkat, admin TI dapat mencabut sesi pengguna. Namun, aplikasi di perangkat yang hilang dapat terus mengakses Microsoft Graph untuk pengguna hingga token kedaluwarsa. Evaluasi akses berkelanjutan (CAE) Microsoft dapat mencegah akses setelah pencabutan sesi pengguna untuk aplikasi yang mengadopsi CAE. Jika aplikasi Anda memanggil Microsoft Graph setidaknya sekali dalam satu jam, maka Anda dapat mengadopsi CAE. Cara menggunakan API berkemampuan Evaluasi Akses Berkelanjutan di aplikasi Anda menyediakan detail implementasi.

Jika Anda tidak dapat membangun MSAL, aplikasi Anda harus menggunakan OAuth 2.0 untuk meminta token akses dari ID Microsoft Entra. platform identitas Microsoft dan alur kode otorisasi OAuth 2.0 menyediakan detail implementasi untuk alur yang didukung MICROSOFT Entra ID.

Jika Anda membuat aplikasi perangkat seluler, tinjau Mendukung SSO dan kebijakan perlindungan aplikasi Anda di aplikasi seluler. Pelajari cara mendukung akuisisi token, manajemen aplikasi seluler (MAM) Intune, dan kebijakan perlindungan aplikasi.

Otorisasi dalam sumber daya (API)

Bagian Otorisasi di aplikasi memperkenalkan tiga otorisasi yang diperlukan ketika aplikasi perlu mengakses sumber daya untuk pengguna tetapi hanya mencakup dua otorisasi pertama. Pengguna harus memiliki otorisasi untuk mengakses sumber daya, tetapi ID Microsoft Entra tidak melakukan otorisasi akhir. Sumber daya (API) melakukan otorisasi.

API harus memberlakukan dua otorisasi saat bertindak untuk pengguna:

• API harus mengotorisasi aplikasi untuk memanggil API. Periksa apakah klaim (cakupan) token scp akses berisi cakupan yang diperlukan.
• API harus mengotorisasi pengguna untuk mengakses sumber daya tertentu. Klaim oid (ID objek) dan sub (subjek) dalam token mewakili identitas pengguna.

Kami merekomendasikan oid klaim dan sub untuk otorisasi.

MICROSOFT Entra ID menerapkan klaim pairwise sub , oleh karena itu sub klaim adalah pengidentifikasi pengguna unik untuk aplikasi yang meminta. Pengguna yang sama yang menggunakan aplikasi lain memiliki klaim yang berbeda sub . Klaim oid ini konstan bagi pengguna untuk semua aplikasi.

Aplikasi menyediakan token akses yang diperlukan ke API yang dilindungi MICROSOFT Entra ID di http header otorisasi permintaan sebagai token pembawa. API harus sepenuhnya memvalidasi token yang diterima karena token tidak berasal langsung dari ID Microsoft Entra. Pertimbangkan aplikasi panggilan sebagai tidak dapat dipercaya hingga validasi token. Artikel referensi token akses dan referensi validasi klaim memberikan detail tentang memvalidasi token akses ID Microsoft Entra.

MICROSOFT Entra ID menerbitkan kunci publik yang digunakan API untuk memvalidasi tanda tangan token. Kunci ini bergulir secara berkala dan setiap kali situasi memerlukan rollover kunci publik. Aplikasi Anda tidak boleh mengasumsikan jadwal yang ditetapkan untuk rollover kunci publik. Penandatanganan rollover kunci di platform identitas Microsoft menjelaskan cara menangani rollover kunci publik dengan benar.

Sebaiknya gunakan pustaka yang dikelola dengan baik untuk melakukan validasi token. Jika Anda membangun aplikasi web atau API di ASP.NET atau ASP.NET Core, gunakan Microsoft.Identity.Web untuk menangani validasi token. Artikel Panduan API web yang dilindungi menjelaskan cara menggunakan Microsoft.Identity.Web untuk melindungi API.

API terkadang perlu memanggil API lain. Saat aplikasi berfungsi untuk pengguna, API menerima token akses yang didelegasikan yang menyertakan identitas pengguna saat ini. Penting bahwa kepercayaan API hanya token yang divalidasi dari ID Microsoft Entra untuk menentukan identitas pengguna saat ini. Pendekatan ini mencegah kompromi aplikasi sehingga pengguna meniru pengguna lain dan mengakses sumber daya untuk pengguna yang berbeda. Untuk perlindungan yang sama ini ketika satu API memanggil API lain, gunakan alur Atas Nama OAuth untuk memperoleh token akses untuk memanggil API bagi pengguna yang API-nya dipanggil. Buat API web yang memanggil API web menyediakan langkah-langkah bagi API untuk memanggil API lain untuk pengguna aplikasi saat ini.

Selain akses yang didelegasikan, API mungkin perlu mendukung aplikasi dan bertindak secara independen tanpa pengguna saat ini. ID Microsoft Entra menyebut aplikasi ini sebagai beban kerja. Untuk menerapkan otorisasi beban kerja, API tidak menggunakan scp klaim (cakupan). Sebagai gantinya roles , API menggunakan klaim untuk memvalidasi bahwa beban kerja memiliki persetujuan yang diperlukan. API bertanggung jawab untuk menegakkan bahwa beban kerja memiliki otorisasi untuk mengakses sumber daya.

Otorisasi dalam beban kerja

Beban kerja adalah aplikasi yang bekerja secara independen dan tidak memiliki pengguna saat ini. Seperti akses yang didelegasikan yang dibahas di bagian Otorisasi di aplikasi , akses khusus aplikasi memerlukan beberapa otorisasi:

• Aplikasi harus memiliki otorisasi untuk mengakses operasi tertentu dalam sumber daya tertentu.
• Aplikasi harus memiliki otorisasi untuk mengakses sumber daya dalam kondisi saat ini.
• Aplikasi harus memiliki otorisasi untuk mengakses sumber daya.

Proses dimulai dengan beban kerja yang meminta token akses dengan .default cakupan (seperti https://graph.microsoft.com/.default). Tidak seperti akses yang didelegasikan (aplikasi dapat meminta cakupan secara dinamis dan bertahap), beban kerja harus selalu menggunakan persetujuan statis dan .default cakupan.

Perancang API membuat izin aplikasi untuk API mereka dengan menambahkan peran ke pendaftaran aplikasi API. Peran ini memiliki jenis aplikasi anggota yang diizinkan, yang memungkinkan penetapan peran ke beban kerja. Tetapkan peran ke beban kerja di pusat admin Microsoft Entra atau dengan Microsoft Graph. Di pusat admin Microsoft Entra, persetujuan admin untuk peran yang ditetapkan diperlukan sebelum beban kerja dapat berjalan.

Secara default, izin aplikasi mengotorisasi beban kerja untuk mengakses semua instans sumber daya. Misalnya,https://graph.microsoft.com/user.read.all mengotorisasi beban kerja untuk mengakses profil pengguna lengkap setiap pengguna di penyewa. Admin TI sering kali enggan memberikan izin luas ini.

Untuk beban kerja yang mengakses Microsoft Graph, gunakan metode ini untuk membatasi izin aplikasi:

• Microsoft Teams menerapkan persetujuan khusus sumber daya.
• Exchange Online menerapkan kebijakan akses aplikasi.
• SharePoint mengimplementasikan Sites.Selected cakupan untuk persetujuan khusus sumber daya.

Tidak seperti aplikasi dengan pengguna, beban kerja mengautentikasi diri mereka ke ID Microsoft Entra.

Untuk beban kerja yang berjalan di Microsoft Azure, metode terbaik untuk beban kerja untuk mengautentikasi dirinya sendiri adalah identitas terkelola untuk sumber daya Azure. Fitur identitas terkelola menghapus kebutuhan untuk mengelola kredensial untuk beban kerja. Tidak ada kredensial yang dapat diakses. MICROSOFT Entra ID sepenuhnya mengelola kredensial. Tanpa kredensial untuk dikelola, tidak ada kredensial yang berisiko disusupi.

Dengan peningkatan keamanan, identitas terkelola juga meningkatkan ketahanan. Identitas terkelola menggunakan token akses berumur panjang dan informasi dari ID Microsoft Entra untuk mendapatkan token baru sebelum token kedaluwarsa. 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.

Jika beban kerja tidak berjalan di Microsoft Azure, beban kerja harus mengautentikasi dirinya sendiri dengan alur kredensial klien OAuth 2.0.

MICROSOFT Entra ID mendukung jenis kredensial klien ini:

• Sertifikat. Beban kerja membuktikan bahwa mereka memiliki kunci privat dengan menandatangani pernyataan dengan kunci privat. Kunci privat tidak dikirimkan ke ID Microsoft Entra. Hanya pernyataan yang dikirim. Kami merekomendasikan sertifikat alih-alih rahasia klien karena lebih aman dan sering dikelola dengan lebih baik.
• Kredensial federasi. Federasi identitas beban kerja memungkinkan beban kerja yang tidak berjalan di Microsoft Azure untuk menggunakan identitas dari penyedia identitas lain, GitHub Actions, atau kluster Kubernetes. Beban kerja meminta token dengan cara yang sama untuk kredensial federasi seperti untuk kredensial sertifikat. Perbedaannya adalah bahwa pernyataan, JSON Web Token yang ditandatangani, berasal dari penyedia identitas federasi.
• Rahasia klien. Terkadang disebut kata sandi aplikasi, rahasia klien adalah nilai string yang dapat digunakan beban kerja untuk mengidentifikasi dirinya sendiri. Nilai teks rahasia dikirim dari beban kerja ke ID Microsoft Entra dalam permintaan POST untuk token. Rahasia klien kurang aman daripada sertifikat atau federasi identitas beban kerja. Jika beban kerja Anda menggunakan rahasia, ikuti praktik terbaik ini untuk mengelola rahasia.

Selain ID Microsoft Entra, keluarga produk Microsoft Entra menyertakan ID Beban Kerja Microsoft Entra. ID Beban Kerja Microsoft Entra memiliki fitur premium berikut untuk meningkatkan keamanan beban kerja.

• Akses Bersyar mendukung kebijakan berbasis lokasi atau risiko untuk identitas beban kerja.
• Microsoft Entra ID Protection menyediakan laporan tentang kredensial yang disusupi, masuk anomali, dan perubahan mencurigakan pada akun.
• Tinjauan akses memungkinkan delegasi tinjauan kepada orang yang tepat, berfokus pada peran istimewa yang paling penting.
• Rekomendasi kesehatan aplikasi menyarankan cara untuk mengatasi kesenjangan kebersihan identitas dalam portofolio aplikasi Anda dan meningkatkan postur keamanan dan ketahanan penyewa.

Beban kerja dapat mendukung Evaluasi Akses Berkelanjutan (CAE) jika mereka memanggil Microsoft Graph setidaknya satu jam sekali. Untuk mendukung CAE, beban kerja harus berupa aplikasi penyewa tunggal dan aplikasi yang terdaftar di penyewa tempat aplikasi mengakses Microsoft Graph. Jika beban kerja Anda memenuhi persyaratan ini, lihat sampel ini untuk langkah-langkah implementasi.

Langkah berikutnya

• ID Microsoft Entra untuk Pengembang Perangkat Lunak Independen menjelaskan cara menggunakan layanan manajemen identitas dan akses berbasis cloud ini untuk memungkinkan karyawan mengakses sumber daya dengan aplikasi Anda.
• Membuat aplikasi di ekosistem ID Microsoft Entra menjelaskan cara menggunakan pusat admin Microsoft Entra atau Microsoft Graph API untuk mendaftarkan aplikasi di penyewa ID Microsoft Entra.
• Mengautentikasi aplikasi dan pengguna menjelaskan cara aplikasi menggunakan ID Microsoft Entra untuk mengautentikasi pengguna dan aplikasi.
• Menyesuaikan token membantu Anda membangun keamanan ke dalam aplikasi dengan token ID dan token akses dari ID Microsoft Entra. Ini menjelaskan informasi yang dapat Anda terima di token ID Microsoft Entra dan bagaimana Anda dapat menyesuaikannya.