Bagikan melalui

Mengonfigurasi App Service atau aplikasi Azure Functions Anda untuk menggunakan masuk Microsoft Entra

  • Artikel

Catatan

Mulai 1 Juni 2024, semua aplikasi App Service yang baru dibuat akan memiliki opsi untuk membuat nama host default unik dengan konvensi penamaan <app-name>-<random-hash>.<region>.azurewebsites.net. . Nama aplikasi yang ada tidak akan berubah.

Contoh: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Untuk informasi selengkapnya, lihat Nama Host Default Unik untuk Sumber Daya App Service.

Pilih penyedia autentikasi lain untuk melompat ke dalamnya.

Artikel ini memperlihatkan kepada Anda cara mengonfigurasi autentikasi untuk Azure App Service atau Azure Functions sehingga aplikasi Anda memasukkan pengguna dengan platform identitas Microsoft (Microsoft Entra) sebagai penyedia autentikasi.

Pilih penyewa untuk aplikasi Anda dan penggunanya

Sebelum aplikasi Anda dapat memasukkan pengguna, Anda harus terlebih dahulu mendaftarkannya di tenaga kerja atau penyewa eksternal. Jika Anda membuat aplikasi tersedia untuk tamu karyawan atau bisnis, daftarkan aplikasi Anda di penyewa tenaga kerja. Jika aplikasi Anda adalah untuk konsumen dan pelanggan bisnis, daftarkan di penyewa eksternal.

  1. Masuk ke portal Microsoft Azure dan navigasikan ke aplikasi Anda.

  2. Di menu kiri aplikasi Anda, pilih Autentikasi, lalu pilih Tambahkan IdP.

  3. Di halaman Tambahkan idP , pilih Microsoft sebagai Penyedia identitas untuk masuk ke Identitas Microsoft dan Microsoft Entra.

  4. Untuk Jenis penyewa, pilih Konfigurasi tenaga kerja (penyewa saat ini) untuk karyawan dan tamu bisnis atau pilih Konfigurasi eksternal untuk konsumen dan pelanggan bisnis.

Pilih pendaftaran aplikasi

Fitur Autentikasi App Service dapat secara otomatis membuat pendaftaran aplikasi untuk Anda atau Anda dapat menggunakan pendaftaran yang Anda atau admin direktori buat secara terpisah.

Buat pendaftaran aplikasi baru secara otomatis, kecuali Anda perlu membuat pendaftaran aplikasi secara terpisah. Anda dapat menyesuaikan pendaftaran aplikasi di pusat admin Microsoft Entra nanti jika anda mau.

Situasi berikut adalah kasus paling umum untuk menggunakan pendaftaran aplikasi yang ada:

  • Akun Anda tidak memiliki izin untuk membuat pendaftaran aplikasi di penyewa Microsoft Entra Anda.
  • Anda ingin menggunakan pendaftaran aplikasi dari penyewa Microsoft Entra yang berbeda dari yang ada di aplikasi Anda.
  • Opsi untuk membuat pendaftaran baru tidak tersedia untuk cloud pemerintah.

Buat dan gunakan pendaftaran aplikasi baru atau gunakan pendaftaran yang sudah ada yang dibuat secara terpisah.

Opsi 1: Membuat dan menggunakan pendaftaran aplikasi baru

Gunakan opsi ini kecuali Anda perlu membuat pendaftaran aplikasi secara terpisah. Anda dapat menyesuaikan pendaftaran aplikasi di Microsoft Entra setelah dibuat.

Catatan

Opsi untuk membuat pendaftaran baru secara otomatis tidak tersedia untuk cloud pemerintah. Sebagai gantinya, tentukan pendaftaran secara terpisah.

Masukkan Nama untuk pendaftaran aplikasi baru.

Pilih Jenis akun yang didukung:

  • Penyewa saat ini - Penyewa tunggal. Akun hanya dalam direktori organisasi ini. Semua akun pengguna dan tamu di direktori Anda dapat menggunakan aplikasi atau API Anda. Gunakan opsi ini jika audiens target Anda bersifat internal pada organisasi Anda.
  • Direktori Microsoft Entra apa pun - Multipenyewa. Akun dalam direktori organisasi apa pun. Semua pengguna dengan akun kerja atau sekolah dari Microsoft dapat menggunakan aplikasi atau API Anda. Ini termasuk sekolah dan bisnis yang menggunakan Office 365. Gunakan opsi ini jika audiens target Anda adalah pelanggan bisnis atau pendidikan dan untuk mengaktifkan multipenyewa.
  • Direktori Microsoft Entra & akun Microsoft pribadi apa pun. Akun di direktori organisasi dan akun Microsoft pribadi apa pun (misalnya, Skype, Xbox). Semua pengguna dengan akun Microsoft kantor atau sekolah, atau pribadi dapat menggunakan aplikasi atau API Anda. Ini termasuk sekolah dan bisnis yang menggunakan Office 365 serta akun pribadi yang digunakan untuk masuk ke layanan seperti Xbox dan Skype. Gunakan opsi ini untuk menargetkan kumpulan identitas Microsoft terluas dan untuk mengaktifkan multipenyewa.
  • Akun Microsoft pribadi saja. Akun pribadi yang digunakan untuk masuk ke layanan seperti Xbox dan Skype. Gunakan opsi ini untuk menargetkan kumpulan identitas Microsoft terluas.

Anda dapat mengubah nama pendaftaran atau jenis akun yang didukung nanti jika anda mau.

Rahasia klien dibuat sebagai pengaturan aplikasi slot-sticky bernama MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Anda dapat memperbarui pengaturan tersebut nanti untuk menggunakan referensi Key Vault jika Anda ingin mengelola rahasia di Azure Key Vault.

Opsi 2: Gunakan pendaftaran yang sudah ada yang dibuat secara terpisah

Yaitu:

  • Pilih Pilih pendaftaran aplikasi yang sudah ada di direktori ini dan pilih pendaftaran aplikasi dari menu drop-down.
  • Pilih Berikan detail pendaftaran aplikasi yang ada dan berikan:
    • ID aplikasi (klien).
    • Rahasia klien (disarankan). Nilai rahasia yang digunakan aplikasi untuk membuktikan identitasnya saat meminta token. Nilai ini disimpan dalam konfigurasi aplikasi Anda sebagai pengaturan aplikasi slot-sticky bernama MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Jika rahasia klien tidak diatur, operasi masuk dari layanan menggunakan alur pemberian implisit OAuth 2.0, yang tidak direkomendasikan* .
    • URL Penerbit, yang mengambil formulir <authentication-endpoint>/<tenant-id>/v2.0. Ganti <authentication-endpoint> dengan nilai titik akhir autentikasi khusus untuk lingkungan cloud. Misalnya, penyewa tenaga kerja di Azure global akan menggunakan "https://login.microsoftonline.com" sebagai titik akhir autentikasinya.

Jika Anda perlu membuat pendaftaran aplikasi secara manual di penyewa tenaga kerja, ikuti mulai cepat mendaftarkan aplikasi . Saat Anda melalui proses pendaftaran, pastikan untuk mencatat ID aplikasi (klien) dan nilai rahasia klien.

Selama proses pendaftaran, di bagian URI Pengalihan, pilih Web untuk platform dan ketik <app-url>/.auth/login/aad/callback. Contohnya,https://contoso.azurewebsites.net/.auth/login/aad/callback.

Setelah pembuatan, ubah pendaftaran aplikasi:

  1. Dari navigasi kiri, pilih Ekspos API>Tambahkan>Simpan. Nilai ini secara unik mengidentifikasi aplikasi ketika digunakan sebagai sumber daya, memungkinkan token yang memberikan akses untuk diminta. Ini digunakan sebagai awalan untuk cakupan yang Anda buat.

    Untuk aplikasi penyewa tunggal, Anda dapat menggunakan nilai default, yang berupa api://<application-client-id>. Anda juga dapat menentukan URI yang lebih mudah dibaca seperti https://contoso.com/api berdasarkan salah satu domain terverifikasi untuk penyewa Anda. Untuk aplikasi multipenyewa, Anda harus menyediakan URI kustom. Untuk mempelajari selengkapnya tentang format yang diterima untuk URI ID Aplikasi, lihat referensi praktik terbaik pendaftaran aplikasi.

  2. Pilih Tambahkan cakupan.

    1. Di Nama cakupan, masukkan user_impersonation.
    2. Di Siapa dapat menyetujui, pilih Admin dan pengguna jika Anda ingin mengizinkan pengguna menyetujui cakupan ini.
    3. Dalam kotak teks, masukkan deskripsi dan nama cakupan persetujuan yang Anda inginkan dilihat pengguna di halaman persetujuan. Misalnya, masukkan Akses <application-name>.
    4. Pilih Tambahkan cakupan.

  3. (Disarankan) Untuk membuat rahasia klien:

    1. Dari navigasi kiri, pilih Sertifikat & rahasia>Rahasia klien>Rahasia klien baru.
    2. Masukkan deskripsi serta kedaluwarsa dan pilih Tambahkan.
    3. Di bidang Nilai, salin nilai rahasia klien. Ini tidak akan ditampilkan lagi setelah Anda menavigasi menjauh dari halaman ini.

  4. (Opsional) Untuk menambahkan beberapa URL Balasan, pilih Autentikasi.

Mengonfigurasi pemeriksaan tambahan

Konfigurasikan Pemeriksaan tambahan, yang menentukan permintaan mana yang diizinkan untuk mengakses aplikasi Anda. Anda dapat menyesuaikan perilaku ini sekarang atau menyesuaikan pengaturan ini nanti dari layar Autentikasi dengan memilih Edit di samping Pengaturan autentikasi.

Untuk persyaratan aplikasi Klien, pilih apakah akan:

  • Izinkan permintaan hanya dari aplikasi ini sendiri
  • Mengizinkan permintaan dari aplikasi klien tertentu
  • Mengizinkan permintaan dari aplikasi apa pun (Tidak disarankan)

Untuk Persyaratan identitas, pilih apakah akan:

  • Mengizinkan permintaan dari identitas apa pun
  • Mengizinkan permintaan dari identitas tertentu

Untuk persyaratan Penyewa, pilih apakah akan:

  • Izinkan permintaan hanya dari penyewa penerbit
  • Mengizinkan permintaan dari penyewa tertentu
  • Menggunakan pembatasan default berdasarkan pengeluar sertifikat

Aplikasi Anda mungkin masih perlu membuat keputusan otorisasi tambahan dalam kode. Untuk informasi selengkapnya, lihat Menggunakan kebijakan otorisasi bawaan.

Mengonfigurasi pengaturan autentikasi

Opsi ini menentukan bagaimana aplikasi Anda merespons permintaan yang tidak diautentikasi, dan pilihan default akan mengalihkan semua permintaan untuk masuk dengan penyedia baru ini. Anda dapat mengubah kustomisasi perilaku ini sekarang atau menyesuaikan pengaturan ini nanti dari layar Autentikasi dengan memilih Edit di samping Pengaturan autentikasi. Untuk mempelajari selengkapnya tentang opsi ini, lihat Alur autentikasi.

Untuk Membatasi akses, putuskan apakah akan:

  • Memerlukan autentikasi
  • Perbolehkan akses yang tidak diaauthenticated

Untuk permintaan yang tidak diaauthenticated

  • Pengalihan HTTP 302 Ditemukan: direkomendasikan untuk situs web
  • HTTP 401 Tidak Sah: direkomendasikan untuk API
  • Pelarangan HTTP 403
  • HTTP 404 Tidak ditemukan

Pilih Penyimpanan token (disarankan). Penyimpanan token mengumpulkan, menyimpan, dan menyegarkan token untuk aplikasi Anda. Anda dapat menonaktifkannya nanti jika aplikasi Anda tidak memerlukan token atau Anda perlu mengoptimalkan performa.

Menambahkan IdP

Jika Anda memilih konfigurasi tenaga kerja, Anda dapat memilih Berikutnya: Izin dan menambahkan izin Microsoft Graph apa pun yang diperlukan oleh aplikasi. Ini akan ditambahkan ke pendaftaran aplikasi, tetapi Anda juga dapat mengubahnya nanti. Jika Anda memilih konfigurasi eksternal, Anda dapat menambahkan izin Microsoft Graph nanti.

Pilih Tambahkan.

Kini Anda siap menggunakan platform identitas Microsoft untuk autentikasi di aplikasi Anda. Penyedia akan dicantumkan pada layar Autentikasi. Dari sana, Anda dapat mengedit atau menghapus konfigurasi penyedia ini.

Untuk contoh mengonfigurasi masuk Microsoft Entra untuk aplikasi web yang mengakses Azure Storage dan Microsoft Graph, lihat tutorial ini.

Mengotorisasi permintaan

Secara default, Autentikasi App Service hanya menangani autentikasi, menentukan apakah penelepon adalah siapa yang mereka katakan. Otorisasi, menentukan apakah penelepon tersebut harus memiliki akses ke beberapa sumber daya, adalah langkah tambahan di luar autentikasi. Anda dapat mempelajari selengkapnya tentang konsep-konsep ini dari dasar-dasar otorisasi platform identitas Microsoft.

Aplikasi Anda dapat membuat keputusan otorisasi dalam kode. Autentikasi App Service memang menyediakan beberapa pemeriksaan bawaan, yang dapat membantu, tetapi mungkin tidak sendirian cukup untuk mencakup kebutuhan otorisasi aplikasi Anda.

Tip

Aplikasi multi-penyewa harus memvalidasi penerbit dan ID penyewa permintaan sebagai bagian dari proses ini untuk memastikan nilai diizinkan. Saat Autentikasi App Service dikonfigurasi untuk skenario multi-penyewa, itu tidak memvalidasi penyewa mana yang berasal dari permintaan. Aplikasi mungkin perlu dibatasi untuk penyewa tertentu, berdasarkan apakah organisasi telah mendaftar untuk layanan, misalnya. Lihat panduan multi-penyewa platform identitas Microsoft.

Melakukan validasi dari kode aplikasi

Saat melakukan pemeriksaan otorisasi di kode aplikasi, Anda dapat menggunakan informasi klaim yang tersedia untuk Autentikasi App Service. Header yang disuntikkan x-ms-client-principal berisi objek JSON yang dikodekan Base64 dengan klaim yang ditegaskan tentang pemanggil. Secara default, klaim ini melalui pemetaan klaim, sehingga nama klaim mungkin tidak selalu cocok dengan apa yang akan Anda lihat dalam token. Misalnya, klaim dipetakan tid ke http://schemas.microsoft.com/identity/claims/tenantid sebagai gantinya.

Anda juga dapat bekerja langsung dengan token akses yang mendasar dari header yang disuntikkan x-ms-token-aad-access-token .

Menggunakan kebijakan otorisasi bawaan

Pendaftaran aplikasi yang dibuat mengautentikasi permintaan masuk untuk penyewa Microsoft Entra Anda. Secara default, ini juga memungkinkan siapa pun dalam penyewa untuk mengakses aplikasi, yang baik-baik saja untuk banyak aplikasi. Namun, beberapa aplikasi perlu membatasi akses lebih lanjut dengan membuat keputusan otorisasi. Kode aplikasi Anda sering menjadi tempat terbaik untuk menangani logika otorisasi kustom. Namun, untuk skenario umum, platform identitas Microsoft menyediakan pemeriksaan bawaan yang dapat Anda gunakan untuk membatasi akses.

Bagian ini menunjukkan cara mengaktifkan pemeriksaan bawaan menggunakan API V2 autentikasi App Service. Saat ini, satu-satunya cara untuk mengonfigurasi pemeriksaan bawaan ini adalah melalui templat Azure Resource Manager atau REST API.

Dalam objek API, konfigurasi penyedia identitas Microsoft Entra memiliki validation bagian yang dapat menyertakan defaultAuthorizationPolicy objek seperti dalam struktur berikut:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Properti Deskripsi
defaultAuthorizationPolicy Pengelompokan persyaratan yang harus dipenuhi untuk mengakses aplikasi. Akses diberikan berdasarkan logis AND atas setiap properti yang dikonfigurasi. Ketika allowedApplications dan allowedPrincipals keduanya dikonfigurasi, permintaan masuk harus memenuhi kedua persyaratan agar dapat diterima.
allowedApplications Daftar izin ID klien aplikasi string yang mewakili sumber daya klien yang memanggil ke dalam aplikasi. Ketika properti ini dikonfigurasi sebagai array nonempty, hanya token yang diperoleh oleh aplikasi yang ditentukan dalam daftar yang akan diterima.

Kebijakan ini mengevaluasi appid atau azp klaim token masuk, yang harus menjadi token akses. Lihat referensi klaim platform identitas Microsoft.
allowedPrincipals Pengelompokan pemeriksaan yang menentukan apakah perwakilan yang diwakili oleh permintaan masuk dapat mengakses aplikasi. Kepuasan allowedPrincipals didasarkan pada logis OR atas properti yang dikonfigurasi.
identities (di bawah allowedPrincipals) Daftar izin ID objek string yang mewakili pengguna atau aplikasi yang memiliki akses. Ketika properti ini dikonfigurasi sebagai array yang tidak ada, allowedPrincipals persyaratan dapat dipenuhi jika pengguna atau aplikasi yang diwakili oleh permintaan ditentukan dalam daftar. Ada batas total 500 karakter di seluruh daftar identitas.

Kebijakan ini mengevaluasi oid klaim token masuk. Lihat referensi klaim platform identitas Microsoft.

Selain itu, beberapa pemeriksaan dapat dikonfigurasi melalui pengaturan aplikasi, terlepas dari versi API yang digunakan. WEBSITE_AUTH_AAD_ALLOWED_TENANTS Pengaturan aplikasi dapat dikonfigurasi dengan daftar yang dipisahkan koma hingga 10 ID penyewa (misalnya, "559a2f9c-c6f2-4d31-b8d6-5ad1a13f8330,5693f64a-3ad5-4be7-b846-e9d1141bcebc") untuk mengharuskan token masuk berasal dari salah satu penyewa yang ditentukan, seperti yang ditentukan oleh tid klaim. WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL Pengaturan aplikasi dapat dikonfigurasi ke "true" atau "1" untuk mengharuskan token masuk menyertakan oid klaim. Pengaturan ini diabaikan dan diperlakukan sebagai benar jika allowedPrincipals.identities telah dikonfigurasi (karena oid klaim diperiksa terhadap daftar identitas yang disediakan ini).

Permintaan yang gagal pemeriksaan bawaan ini diberikan respons HTTP 403 Forbidden .

Mengonfigurasi aplikasi klien untuk mengakses App Service Anda

Di bagian sebelumnya, Anda mendaftarkan App Service atau Azure Function untuk mengautentikasi pengguna. Bagian ini menjelaskan cara mendaftarkan klien asli atau aplikasi daemon di Microsoft Entra sehingga mereka dapat meminta akses ke API yang diekspos oleh App Service Anda atas nama pengguna atau diri mereka sendiri, seperti dalam arsitektur N-tingkat. Menyelesaikan langkah di bagian ini tidak diperlukan jika Anda hanya ingin mengautentikasi pengguna.

Aplikasi klien asli

Anda dapat mendaftarkan klien asli untuk meminta akses API aplikasi App Service Anda atas nama pengguna yang login.

  1. Dari menu portal, pilih Microsoft Entra.

  2. Dari navigasi kiri, pilih Pendaftaran aplikasi> Pendaftaran baru.

  3. Di halaman Daftarkan aplikasi, masukkan Nama untuk pendaftaran aplikasi Anda.

  4. Di URI Pengalihan, pilih Klien publik (mobile & desktop) dan ketik URL-nya <app-url>/.auth/login/aad/callback. Contohnya,https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Pilih Daftarkan.

  6. Setelah pendaftaran aplikasi dibuat, salin nilai ID Aplikasi (klien).

    Catatan

    Untuk aplikasi Microsoft Store, gunakan paket SID sebagai URI sebagai gantinya.

  7. Dari navigasi kiri, pilih Izin>API Tambahkan izin>API Saya.

  8. Pilih pendaftaran aplikasi yang Anda buat sebelumnya untuk aplikasi App Service Anda. Jika Anda tidak melihat pendaftaran aplikasi, pastikan Anda telah menambahkan cakupan user_impersonation dalam pendaftaran aplikasi.

  9. Di bawah Izin yang didelegasikan, pilih user_impersonation, lalu pilih Tambahkan izin.

Kini Anda telah mengonfigurasi aplikasi klien asli yang dapat meminta akses aplikasi Layanan Aplikasi atas nama pengguna.

Aplikasi klien Daemon (panggilan layanan ke layanan)

Dalam arsitektur N-tingkat, aplikasi klien Anda dapat memperoleh token untuk memanggil App Service atau aplikasi Fungsi atas nama aplikasi klien itu sendiri (bukan atas nama pengguna). Skenario ini berguna untuk aplikasi daemon non-interaktif yang melakukan tugas tanpa pengguna yang masuk. Ini menggunakan pemberian informasi masuk klien OAuth 2.0 standar.

  1. Dari menu portal, pilih Microsoft Entra.
  2. Dari navigasi kiri, pilih Pendaftaran aplikasi> Pendaftaran baru.
  3. Di halaman Daftarkan aplikasi, masukkan Nama untuk pendaftaran aplikasi Anda.
  4. Untuk aplikasi daemon, Anda tidak memerlukan URI Pengalihan sehingga Anda dapat menyimpannya tetap kosong.
  5. Pilih Daftarkan.
  6. Setelah pendaftaran aplikasi dibuat, salin nilai ID Aplikasi (klien).
  7. Dari navigasi kiri, pilih Sertifikat & rahasia>Rahasia klien>Rahasia klien baru.
  8. Masukkan deskripsi serta kedaluwarsa dan pilih Tambahkan.
  9. Di bidang Nilai, salin nilai rahasia klien. Ini tidak akan ditampilkan lagi setelah Anda menavigasi menjauh dari halaman ini.

Anda sekarang dapat meminta token akses menggunakan ID klien dan rahasia klien dengan mengatur parameter resource ke URI ID Aplikasi pada aplikasi target. Token akses yang dihasilkan kemudian dapat disajikan ke aplikasi target menggunakan header Otorisasi OAuth 2.0 standar, dan autentikasi App Service akan memvalidasi dan menggunakan token seperti biasa untuk sekarang menunjukkan bahwa pemanggil (aplikasi dalam hal ini, bukan pengguna) diautentikasi.

Saat ini, ini memungkinkan aplikasi klien apa pun di penyewa Microsoft Entra Anda untuk meminta token akses dan mengautentikasi ke aplikasi target. Jika Anda juga ingin menerapkan otorisasi untuk hanya mengizinkan aplikasi klien tertentu, Anda harus melakukan beberapa konfigurasi tambahan.

  1. Tentukan Peran Aplikasi dalam manifes pendaftaran aplikasi yang mewakili aplikasi App Service atau Function yang ingin Anda lindungi.
  2. Pada pendaftaran aplikasi yang mewakili klien yang perlu diotorisasi, pilih izin API>Tambahkan izin>API Saya.
  3. Pilih pendaftaran aplikasi yang Anda buat sebelumnya. Jika Anda tidak melihat pendaftaran aplikasi, pastikan Anda telah menambahkan Peran Aplikasi.
  4. Di bawah Izin aplikasi, pilih Peran Aplikasi yang Anda buat sebelumnya, lalu pilih Tambahkan izin.
  5. Pastikan untuk pilih Beri persetujuan admin untuk memberi otorisasi aplikasi klien untuk meminta izin.
  6. Mirip dengan skenario sebelumnya (sebelum peran ditambahkan), Anda sekarang dapat meminta token akses untuk target yang sama resource, dan token akses akan mencakup klaim roles yang berisi Peran Aplikasi yang diizinkan untuk aplikasi klien.
  7. Dalam kode aplikasi App Service atau Function target, Anda sekarang dapat memvalidasi bahwa peran yang diharapkan ada dalam token (ini tidak dilakukan oleh autentikasi App Service). Untuk informasi selengkapnya, lihat Mengakses klaim pengguna.

Kini Anda telah mengonfigurasi aplikasi klien daemon yang dapat mengakses aplikasi App Service menggunakan identitasnya sendiri.

Praktik terbaik

Terlepas dari konfigurasi yang Anda gunakan untuk menyiapkan autentikasi, praktik terbaik berikut menjaga penyewa dan aplikasi Anda lebih aman:

  • Konfigurasikan setiap aplikasi App Service dengan pendaftaran aplikasinya sendiri di Microsoft Entra.
  • Berikan setiap aplikasi App Service izin dan persetujuannya sendiri.
  • Hindari berbagi izin antar lingkungan dengan menggunakan pendaftaran aplikasi terpisah untuk slot penyebaran terpisah. Saat Anda menguji kode baru, praktik ini dapat membantu mencegah masalah memengaruhi aplikasi produksi.

Bermigrasi ke Microsoft Graph

Beberapa aplikasi lama mungkin juga telah disiapkan dengan dependensi pada Azure AD Graph yang tidak digunakan lagi, yang dijadwalkan untuk penghentian penuh. Misalnya, kode aplikasi Anda mungkin telah memanggil Azure AD Graph untuk memeriksa keanggotaan grup sebagai bagian dari filter otorisasi di alur middleware. Aplikasi harus berpindah ke Microsoft Graph dengan mengikuti panduan yang disediakan oleh Microsoft Entra sebagai bagian dari proses penghentian Azure AD Graph. Dalam mengikuti instruksi tersebut, Anda mungkin perlu membuat beberapa perubahan pada konfigurasi autentikasi App Service Anda. Setelah menambahkan izin Microsoft Graph ke pendaftaran aplikasi, Anda dapat:

  1. Perbarui URL Penerbit untuk menyertakan akhiran "/v2.0" jika belum.

  2. Hapus permintaan untuk izin Azure AD Graph dari konfigurasi masuk Anda. Properti yang akan diubah bergantung pada versi API manajemen mana yang Anda gunakan:

    • Jika Anda menggunakan API V1 (/authsettings), ini akan berada dalam additionalLoginParams array.
    • Jika Anda menggunakan API V2 (/authsettingsV2), ini akan berada dalam loginParameters array.

    Anda perlu menghapus referensi apa pun ke "https://graph.windows.net", misalnya. Ini termasuk resource parameter (yang tidak didukung oleh titik akhir "/v2.0"), atau cakupan apa pun yang Anda minta secara khusus yang berasal dari Azure AD Graph.

    Anda juga perlu memperbarui konfigurasi untuk meminta izin Microsoft Graph baru yang Anda siapkan untuk pendaftaran aplikasi. Anda dapat menggunakan cakupan .default untuk menyederhanakan penyiapan ini dalam banyak kasus. Untuk melakukannya, tambahkan parameter scope=openid profile email https://graph.microsoft.com/.defaultmasuk baru .

Dengan perubahan ini, ketika Autentikasi App Service mencoba masuk, itu tidak akan lagi meminta izin ke Azure AD Graph, dan sebaliknya akan mendapatkan token untuk Microsoft Graph. Setiap penggunaan token tersebut dari kode aplikasi Anda juga perlu diperbarui, sesuai panduan yang disediakan oleh Microsoft Entra.

Langkah berikutnya