Konfigurasikan layanan aplikasi atau aplikasi Azure Functions Anda untuk menggunakan masuk ke Microsoft Entra

Pilih penyedia autentikasi lain untuk beralih kepadanya.

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 perlu mendaftarkannya di penyewa tenaga kerja atau penyewa eksternal. Jika Anda menghadirkan aplikasi untuk tamu karyawan atau tamu bisnis, daftarkan aplikasi Anda di tenant perusahaan. Jika aplikasi Anda adalah untuk konsumen dan pelanggan bisnis, daftarkan di penyewa eksternal.

  1. Masuk ke portal Microsoft Azure dan buka aplikasi App Service atau aplikasi Functions Anda.

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

  3. Pada halaman Tambahkan penyedia identitas, pilih Microsoft sebagai nilai Penyedia identitas untuk masuk dengan identitas Microsoft dan Microsoft Entra.

  4. Di bawah Pilih penyewa untuk aplikasi Anda dan penggunanya, pilih:

    • Konfigurasi tenaga kerja (penyewa saat ini) untuk karyawan dan tamu bisnis
    • 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 berisi aplikasi Anda. Ini selalu terjadi jika Anda memilih Konfigurasi eksternal saat Anda memilih penyewa.
  • Opsi untuk membuat pendaftaran baru tidak tersedia untuk cloud pemerintah.

Opsi 1: Membuat dan menggunakan pendaftaran aplikasi baru

  1. Pilih Buat pendaftaran aplikasi baru.

  2. Untuk Nama, masukkan nama pendaftaran aplikasi baru.

  3. Pilih nilai Jenis akun yang didukung :

    • Penyewa saat ini - penyewa tunggal: Hanya akun 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 untuk organisasi Anda.
    • Direktori Microsoft Entra apa pun - multitenan: Akun di direktori organisasi mana pun. Semua pengguna dengan akun kerja atau sekolah dari Microsoft dapat menggunakan aplikasi atau API Anda. Akun ini mencakup sekolah dan bisnis yang menggunakan Office 365. Gunakan opsi ini jika audiens target Anda adalah pelanggan bisnis atau pendidikan dan untuk mengaktifkan multitenansi.
    • Direktori Microsoft Entra apa pun & akun Microsoft pribadi: Akun di direktori organisasi mana pun dan akun Microsoft pribadi (misalnya, Skype atau Xbox). Semua pengguna dengan akun kerja atau sekolah, atau akun Microsoft pribadi, dapat menggunakan aplikasi atau API Anda. Ini termasuk sekolah dan bisnis yang menggunakan Office 365, bersama dengan akun pribadi yang digunakan untuk masuk ke layanan seperti Xbox dan Skype. Gunakan opsi ini untuk menargetkan kumpulan identitas Microsoft terluas dan untuk mengaktifkan multipenyewaan.
    • Hanya akun Microsoft pribadi: 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 yang tetap pada tempatnya bernama MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Jika Anda ingin mengelola rahasia di Azure Key Vault, Anda dapat memperbarui pengaturan tersebut nanti untuk menggunakan referensi Key Vault. Atau, Anda dapat mengubah ini untuk menggunakan identitas alih-alih rahasia klien.

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

Untuk menggunakan pendaftaran yang sudah ada, pilih:

  • Pilih pendaftaran aplikasi yang ada di direktori ini: Lalu pilih pendaftaran aplikasi dari daftar dropdown.

  • Berikan detail pendaftaran aplikasi yang ada: Kemudian 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 izin implisit OAuth 2.0, yang tidak kami rekomendasikan.

      Anda juga dapat mengonfigurasi aplikasi untuk menggunakan identitas alih-alih rahasia klien.

    • URL Pengeluar Sertifikat. URL ini mengambil formulir <authentication-endpoint>/<tenant-id>/v2.0. Ganti <authentication-endpoint> dengan nilai titik akhir autentikasi yang khusus untuk lingkungan cloud. Misalnya, penyewa tenaga kerja di Azure global akan menggunakan https://login.microsoftonline.com sebagai titik akhir autentikasinya.

      Anda dapat menemukan nilai ini di pusat admin Microsoft Entra. Buka Pendaftaran aplikasi, pilih aplikasi Anda, lalu pilih Titik akhir. Salin titik akhir dokumen metadata OpenID Connect untuk tenant Anda, lalu hapus /.well-known/openid-configuration dari akhir URL tersebut. Misalnya, jika titik akhir metadata adalah https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration, gunakan https://login.microsoftonline.com/<tenant-id>/v2.0 sebagai URL penerbit.

      Nota

      Jika Anda membuat penyedia identitas menggunakan penyiapan ekspres (Opsi 1), URL penerbit secara otomatis diatur untuk menggunakan endpoint legacy https://sts.windows.net. Untuk menyelaraskan dengan praktik terbaik Microsoft Entra ID saat ini, edit penyedia identitas Anda dan perbarui URL penerbit untuk menggunakan https://login.microsoftonline.com/<tenant-id>/v2.0 sebagai gantinya.

Jika Anda perlu membuat pendaftaran aplikasi secara manual di penyewa tenaga kerja, lihat Mendaftarkan aplikasi dengan platform identitas Microsoft. 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 masukkan URI pengalihan. Misalnya, masukkan https://contoso.azurewebsites.net/.auth/login/aad/callback.

Sekarang, ubah pendaftaran aplikasi:

  1. Di panel kiri, pilih Ekspos API>Tambahkan>Simpan. Nilai ini secara unik mengidentifikasi aplikasi saat digunakan sebagai sumber daya, yang memungkinkan token yang memberikan akses untuk diminta. Nilai adalah awalan untuk cakupan yang Anda buat.

    Untuk aplikasi penyewa tunggal, Anda dapat menggunakan nilai default, yang ada dalam formulir 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 informasi selengkapnya tentang format yang diterima untuk URI ID aplikasi, lihat Praktik terbaik keamanan untuk properti aplikasi di ID Microsoft Entra.

  2. Pilih Tambahkan cakupan, lalu:

    1. Di Nama cakupan, masukkan user_impersonation.
    2. Di Siapa yang dapat menyetujui, pilih Admin dan pengguna jika Anda ingin mengizinkan pengguna menyetujui cakupan ini.
    3. Masukkan nama cakupan persetujuan. Masukkan deskripsi yang Anda inginkan agar dilihat pengguna di halaman persetujuan. Misalnya, masukkan Nama aplikasiAccess.
    4. Pilih Tambahkan cakupan.

  3. (Disarankan) Buat pernyataan klien untuk aplikasi. Untuk membuat rahasia klien:

    1. Di panel kiri, pilih Sertifikat & rahasia>Rahasia klien>Baru.
    2. Masukkan deskripsi dan kedaluwarsa, lalu pilih Tambahkan.
    3. Di bidang Nilai , salin nilai rahasia klien. Setelah Anda menjauh dari halaman ini, halaman tidak akan muncul lagi.

    Anda juga dapat mengonfigurasi aplikasi untuk menggunakan identitas alih-alih rahasia klien.

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

Mengonfigurasi pemeriksaan tambahan

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

Untuk persyaratan aplikasi Klien, pilih apakah akan:

  • Izinkan permintaan hanya dari aplikasi ini sendiri.
  • Izinkan permintaan dari aplikasi klien tertentu.
  • Izinkan permintaan dari aplikasi apa pun (tidak disarankan).

Untuk Persyaratan identitas, pilih apakah akan:

  • Izinkan permintaan dari identitas apa pun.
  • Izinkan permintaan dari identitas tertentu.

Untuk persyaratan Penyewa, pilih apakah akan:

  • Izinkan permintaan hanya dari penyewa yang sama dengan registrasi aplikasi.
  • Izinkan permintaan dari penyewa tertentu.
  • Gunakan pembatasan default berdasarkan 'tenant' dalam pendaftaran aplikasi.

Untuk Audiens token yang diizinkan, tambahkan setiap nilai audiens yang harus diterima aplikasi Anda pada klaim aud dari token akses yang masuk. Anda biasanya memerlukan pengaturan ini ketika klien meminta token dengan menggunakan URI ID Aplikasi pendaftaran aplikasi, seperti api://<application-client-id> atau URI kustom seperti https://contoso.com/api. ID klien pendaftaran aplikasi sudah diterima secara default, jadi Anda biasanya menambahkan nilai di sini hanya jika aplikasi Anda menerima format audiens lain.

Aplikasi Anda mungkin masih perlu membuat keputusan otorisasi lain dalam kode. Untuk informasi selengkapnya, lihat Menggunakan kebijakan otorisasi bawaan nanti di artikel ini.

Konfigurasikan pengaturan otentikasi

Pengaturan autentikasi menentukan bagaimana aplikasi Anda merespons permintaan yang tidak diautentikasi. Pilihan default mengalihkan semua permintaan untuk masuk dengan penyedia baru ini. Anda dapat menyesuaikan perilaku ini sekarang, atau Anda dapat menyesuaikan pengaturan ini nanti dari halaman Autentikasi utama dengan memilih Edit di samping Pengaturan autentikasi. Untuk informasi selengkapnya, lihat Alur autentikasi.

Untuk Membatasi akses, putuskan apakah akan:

  • Memerlukan autentikasi.
  • Izinkan akses tanpa autentikasi.

Untuk permintaan tanpa autentikasi, pilih opsi kesalahan:

  • HTTP 302 Found redirect: disarankan untuk situs web
  • HTTP 401 Unauthorized: direkomendasikan untuk API
  • HTTP 403 Forbidden
  • HTTP 404 Not found

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

Audiens token yang diizinkan

Pengaturan Audiens token yang diizinkan memungkinkan Anda membatasi token akses mana yang diterima oleh aplikasi App Service atau Azure Functions Anda berdasarkan audiens token (aud klaim).

Secara default, autentikasi App Service menerima token yang dikeluarkan untuk pendaftaran aplikasi yang terkait dengan aplikasi ini. Jika aplikasi Anda mengekspos beberapa API, menggunakan beberapa ID aplikasi, atau diakses melalui URI ID aplikasi kustom, Anda mungkin perlu mengonfigurasi audiens tambahan yang diizinkan secara eksplisit.

Saat dikonfigurasi, hanya token akses yang klaimnya aud cocok dengan salah satu audiens yang diizinkan yang diterima.

Nilai umum meliputi:

  • ID Aplikasi (klien) pendaftaran aplikasi
  • URI ID Aplikasi (misalnya, api://<application-client-id> atau URI kustom seperti https://contoso.com/api)

Anda dapat mengonfigurasi pengaturan ini dari halaman Autentikasi di portal Microsoft Azure:

  1. Buka App Service atau aplikasi Azure Functions Anda.
  2. Pilih Pengaturan > Autentikasi.
  3. Pilih Edit untuk penyedia identitas Microsoft.
  4. Pada bagian Audiens token yang diizinkan, tambahkan satu atau beberapa nilai audiens yang diizinkan.

Pengaturan ini berguna ketika:

  • Aplikasi Anda dipanggil oleh beberapa aplikasi klien menggunakan pengidentifikasi sumber daya yang berbeda.
  • Anda menggunakan URI ID Aplikasi kustom untuk API Anda.
  • Anda ingin secara eksplisit membatasi token mana yang diterima oleh aplikasi.

Jika daftar ini dikonfigurasi, token apa pun yang audiensnya tidak cocok dengan salah satu nilai yang dikonfigurasi ditolak.

Menambahkan penyedia identitas

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

  • Pilih Tambahkan.

Anda sekarang siap menggunakan platform identitas Microsoft untuk autentikasi di aplikasi Anda. Penyedia tercantum di halaman 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 Menambahkan autentikasi aplikasi ke aplikasi web Anda.

Mengotorisasi permintaan

Secara default, autentikasi App Service hanya menangani autentikasi. Ini menentukan apakah penelepon adalah siapa yang mereka katakan. Otorisasi, menentukan apakah penelepon tersebut harus memiliki akses ke beberapa sumber daya, adalah langkah di luar autentikasi. Untuk informasi selengkapnya, lihat Dasar-dasar otorisasi.

Aplikasi Anda dapat membuat keputusan otorisasi dalam kode. Autentikasi App Service menyediakan beberapa pemeriksaan bawaan, yang dapat membantu, tetapi mereka sendiri mungkin tidak cukup untuk mencakup kebutuhan otorisasi aplikasi Anda. Bagian berikut mencakup kemampuan ini.

Petunjuk / Saran

Aplikasi multipenyewa harus memvalidasi penerbit permintaan dan ID penyewa dari permintaan sebagai bagian dari proses ini untuk memastikan nilai tersebut diizinkan. Ketika autentikasi App Service dikonfigurasi untuk skenario multi-penyewa, proses tersebut tidak memvalidasi dari penyewa mana permintaan tersebut berasal. Aplikasi mungkin perlu dibatasi untuk penyewa tertentu, berdasarkan apakah organisasi telah mendaftar untuk layanan (misalnya). Lihat Perbarui kode Anda untuk menangani beberapa nilai penerbit.

Melakukan validasi dari kode aplikasi

Saat melakukan pemeriksaan otorisasi di kode aplikasi Anda, Anda dapat menggunakan informasi klaim identitas yang disediakan oleh autentikasi Layanan Aplikasi. Untuk informasi selengkapnya, lihat Mengakses klaim pengguna dalam kode aplikasi.

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 tid dipetakan ke http://schemas.microsoft.com/identity/claims/tenantid sebagai gantinya.

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

Menggunakan kebijakan otorisasi bawaan

Pendaftaran aplikasi yang telah dibuat akan mengautentikasi permintaan masuk untuk penyewa Microsoft Entra Anda. Secara default, ini juga memungkinkan siapa pun dalam penyewa mengakses aplikasi. Pendekatan ini baik-baik saja untuk banyak aplikasi. 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 dengan menggunakan API V2 autentikasi App Service. Saat ini, satu-satunya cara untuk mengonfigurasi pemeriksaan bawaan ini adalah dengan menggunakan templat Azure Resource Manager atau REST API.

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

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Harta benda Deskripsi
defaultAuthorizationPolicy Sekelompok persyaratan yang harus dipenuhi untuk akses ke aplikasi. Akses diberikan berdasarkan logika AND atas setiap properti yang dikonfigurasi. Ketika allowedApplications dan allowedPrincipals keduanya dikonfigurasi, permintaan masuk harus memenuhi kedua persyaratan untuk 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 diterima.

Kebijakan ini mengevaluasi klaim appid atau azp dari token masuk, yang harus menjadi token akses. Lihat Klaim Payload.
allowedPrincipals Sekelompok pemeriksaan yang menentukan apakah prinsipal yang diwakili oleh permintaan masuk dapat mengakses aplikasi. Kepuasan allowedPrincipals didasarkan pada logika OR atas properti yang telah 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 kosong, persyaratan allowedPrincipals dapat dipenuhi jika pengguna atau aplikasi yang diwakili oleh permintaan tersebut tercantum dalam daftar. Ada batas 500 karakter (total) di seluruh daftar identitas.

Kebijakan ini mengevaluasi klaim oid pada token yang masuk. Lihat Klaim Payload.

Selain itu, Anda dapat mengonfigurasi beberapa pemeriksaan melalui pengaturan aplikasi, terlepas dari versi API yang Anda gunakan. Anda dapat mengonfigurasi pengaturan aplikasi WEBSITE_AUTH_AAD_ALLOWED_TENANTS dengan daftar hingga 10 pengidentifikasi penyewa yang dipisahkan oleh koma; misalnya, aaaabbbb-0000-cccc-1111-dddd2222eeee. Pengaturan ini dapat mengharuskan token masuk berasal dari salah satu penyewa yang ditentukan, sesuai dengan klaim tid.

Anda dapat mengonfigurasi WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL pengaturan aplikasi ke true atau 1, untuk mengharuskan token masuk menyertakan klaim oid. Jika Anda mengonfigurasi allowedPrincipals.identities, pengaturan ini diabaikan dan diperlakukan sebagai benar karena oid klaim diperiksa terhadap daftar identitas yang disediakan ini.

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

Menggunakan identitas terkelola alih-alih rahasia

Alih-alih mengonfigurasi rahasia klien untuk pendaftaran aplikasi, Anda dapat mengonfigurasi aplikasi untuk mempercayai identitas terkelola. Menggunakan identitas alih-alih rahasia berarti Anda tidak perlu mengelola rahasia. Anda tidak memiliki peristiwa kedaluwarsa rahasia untuk ditangani, dan Anda tidak memiliki tingkat risiko yang sama yang terkait dengan kemungkinan mengungkapkan atau membocorkan rahasia itu.

Identitas memungkinkan Anda membuat kredensial identitas federasi, yang dapat digunakan alih-alih rahasia klien sebagai pernyataan klien. Pendekatan ini hanya tersedia untuk konfigurasi tenaga kerja.

Anda dapat menggunakan langkah-langkah di bagian ini untuk mengonfigurasi sumber daya App Service atau Azure Functions Anda untuk menggunakan pola ini. Langkah-langkah di sini mengasumsikan bahwa Anda sudah menyiapkan pendaftaran aplikasi dengan menggunakan salah satu metode yang didukung, dan bahwa Anda sudah memiliki rahasia yang ditentukan.

  1. Buat sumber daya identitas terkelola yang ditetapkan pengguna sesuai dengan petunjuk ini.

  2. Tetapkan identitas tersebut ke sumber daya App Service atau Azure Functions Anda.

    Penting

    Identitas terkelola yang ditetapkan pengguna yang Anda buat hanya boleh ditetapkan ke aplikasi App Service atau Azure Functions melalui pendaftaran ini. Jika Anda menetapkan identitas ke sumber daya lain, Anda memberikan sumber daya tersebut akses yang tidak perlu ke pendaftaran aplikasi Anda.

  3. Catat nilai ID Objek dan ID Klien dari identitas terkelola. Anda akan memerlukan ID objek untuk membuat kredensial identitas federasi di langkah berikutnya. Anda akan menggunakan ID klien identitas terkelola di langkah selanjutnya.

  4. Ikuti instruksi ID Microsoft Entra untuk mengonfigurasi kredensial identitas gabungan pada aplikasi yang sudah ada. Instruksi tersebut juga mencakup bagian untuk memperbarui kode aplikasi, yang dapat Anda lewati.

  5. Tambahkan pengaturan aplikasi baru bernama OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Atur nilainya ke nilai ID Klien identitas terkelola yang Anda peroleh di langkah sebelumnya. Jangan gunakan ID klien pendaftaran aplikasi Anda. Pastikan untuk menandai pengaturan aplikasi ini sebagai slot-sticky.

  6. Di pengaturan autentikasi bawaan untuk sumber daya aplikasi Anda, atur Nama pengaturan rahasia klien ke OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

    Untuk membuat perubahan ini dengan menggunakan portal Microsoft Azure:

    1. Kembali ke sumber daya App Service atau Azure Functions Anda dan pilih tab Autentikasi .
    2. Di bagian Penyedia identitas , untuk entri Microsoft , pilih ikon di kolom Edit .
    3. Dalam dialog Edit penyedia identitas, buka daftar dropdown untuk Nama pengaturan rahasia klien dan pilih OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.
    4. Pilih Simpan.

    Untuk membuat perubahan ini dengan menggunakan REST API:

    • Atur properti clientSecretSettingName ke OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Anda dapat menemukan properti ini di bawah properties>identityProviders>azureActiveDirectory>registration.

  7. Verifikasi bahwa aplikasi berfungsi seperti yang Anda harapkan. Anda seharusnya dapat berhasil melakukan tindakan masuk baru.

Saat Anda puas dengan perilaku menggunakan identitas terkelola, hapus rahasia yang ada:

  1. Pastikan kode aplikasi Anda tidak mengambil dependensi pada pengaturan aplikasi. Jika ya, ikuti instruksi untuk memperbarui kode aplikasi Anda untuk meminta token akses.

  2. Hapus pengaturan aplikasi yang sebelumnya menyimpan rahasia Anda. Nama pengaturan aplikasi ini adalah nilai nama pengaturan rahasia Klien sebelumnya, sebelum Anda mengaturnya ke OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

  3. Masuk ke pusat admin Microsoft Entra dengan menggunakan tenant yang memiliki pendaftaran aplikasi Anda. Buka pendaftaran aplikasi lagi.

  4. Di bawah Sertifikat & rahasia, pilih Rahasia klien dan hapus rahasia klien.

Aplikasi Anda sekarang dikonfigurasi untuk menggunakan autentikasi ID Microsoft Entra tanpa rahasia.

Mengonfigurasi aplikasi klien untuk mengakses App Service

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

Aplikasi klien asli

Anda dapat mendaftarkan klien asli untuk meminta akses ke API aplikasi App Service Anda atas nama pengguna yang masuk:

  1. Pada menu portal Microsoft Azure, pilih ID Microsoft Entra.

  2. Di panel kiri, pilih Kelola>Pendaftaran aplikasi. Lalu pilih Pendaftaran baru.

  3. Pada panel Daftarkan aplikasi , untuk Nama, masukkan nama untuk pendaftaran aplikasi Anda.

  4. Di URI Pengalihan, pilih Klien publik/asli (seluler &desktop) dan masukkan URL pengalihan. Misalnya, masukkan https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Pilih Daftarkan.

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

    Nota

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

  7. Di panel kiri, pilih Kelola>izin API. Lalu pilih Tambahkan izin>API Saya.

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

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

Anda sekarang telah mengonfigurasi aplikasi klien asli yang dapat meminta akses aplikasi App Service Anda 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 Azure Functions 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 kredensial klien OAuth 2.0 standar. Untuk informasi selengkapnya, lihat Platform identitas Microsoft dan alur kredensial klien OAuth 2.0.

  1. Pada menu portal Microsoft Azure, pilih ID Microsoft Entra.

  2. Di panel kiri, pilih Kelola>Pendaftaran aplikasi. Lalu pilih Pendaftaran baru.

  3. Pada panel Daftarkan aplikasi , untuk Nama, masukkan nama untuk pendaftaran aplikasi Anda.

  4. Untuk aplikasi daemon, Anda tidak memerlukan URI pengalihan, sehingga Anda dapat menjaga kotak URI Pengalihan tetap kosong.

  5. Pilih Daftarkan.

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

  7. Di panel kiri, pilih Kelola>Sertifikat & rahasia. Lalu pilih Rahasia Klien>Rahasia Klien Baru.

  8. Masukkan deskripsi dan kedaluwarsa, lalu pilih Tambahkan.

  9. Di bidang Nilai , salin nilai rahasia klien. Setelah Anda menjauh dari halaman ini, halaman tidak akan muncul lagi.

Anda sekarang dapat meminta token akses dengan menggunakan ID klien dan rahasia klien. Atur resource parameter ke nilai URI ID Aplikasi dari aplikasi target. Token akses yang dihasilkan kemudian dapat disajikan ke aplikasi target melalui header Otorisasi OAuth 2.0 standar. Autentikasi App Service memvalidasi dan menggunakan token untuk menunjukkan bahwa pemanggil telah diautentikasi. Dalam hal ini, pemanggil adalah aplikasi, bukan pengguna.

Pendekatan 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 konfigurasi tambahan.

  1. Tentukan peran aplikasi dalam manifes pendaftaran aplikasi yang mewakili aplikasi App Service atau Azure Functions yang ingin Anda lindungi.

  2. Pada pendaftaran aplikasi yang mewakili klien yang perlu diotorisasi, pilih Izin> APITambahkan izin>API Saya.

  3. Pilih pendaftaran aplikasi yang Anda buat sebelumnya. Jika Anda tidak melihat pendaftaran aplikasi, pastikan Anda menambahkan peran aplikasi.

  4. Di bawah Izin aplikasi, pilih peran aplikasi yang Anda buat sebelumnya. Lalu pilih Tambahkan izin.

  5. Pilih Berikan persetujuan admin untuk mengotorisasi aplikasi klien untuk meminta izin.

    Mirip dengan skenario sebelumnya (sebelum menambahkan peran apa pun), Anda sekarang dapat meminta token akses untuk sumber daya target yang sama. Token akses menyertakan roles klaim yang berisi peran aplikasi yang diotorisasi untuk aplikasi klien.

Dalam kode aplikasi App Service atau Azure Functions target, Anda sekarang dapat memvalidasi bahwa token memiliki peran yang diharapkan. Autentikasi App Service tidak melakukan validasi ini. Untuk informasi selengkapnya, lihat Mengakses klaim pengguna dalam kode aplikasi.

Anda sekarang telah mengonfigurasi aplikasi klien daemon yang dapat mengakses aplikasi App Service Anda dengan 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. Gunakan pendaftaran aplikasi terpisah untuk setiap slot penyebaran yang berbeda. Saat Anda menguji kode baru, praktik ini dapat membantu mencegah masalah memengaruhi aplikasi produksi.

Bermigrasi ke Microsoft Graph

Beberapa aplikasi lama mungkin disiapkan dengan dependensi pada Azure AD Graph, yang sudah usang dan dijadwalkan untuk dihentikan sepenuhnya. Misalnya, kode aplikasi Anda mungkin memanggil Azure AD Graph untuk memeriksa keanggotaan grup sebagai bagian dari filter otorisasi dalam alur middleware. Aplikasi harus berpindah ke Microsoft Graph. Untuk informasi selengkapnya, lihat Memigrasikan aplikasi Anda dari Azure AD Graph ke Microsoft Graph.

Selama migrasi ini, Anda mungkin perlu membuat beberapa perubahan pada konfigurasi autentikasi App Service Anda. Setelah menambahkan izin Microsoft Graph ke pendaftaran aplikasi, Anda dapat:

  • Perbarui nilai URL Penerbit untuk menyertakan akhiran /v2.0 jika belum.

  • 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), pengaturan ini ada di additionalLoginParams array.
    • Jika Anda menggunakan API V2 (/authsettingsV2), pengaturan ini ada di loginParameters array.

    Anda perlu menghapus referensi apa pun ke https://graph.windows.net, misalnya. Perubahan ini mencakup parameter resource, yang tidak didukung oleh titik akhir /v2.0. Ini juga mencakup 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. Dalam banyak kasus, Anda dapat menggunakan cakupan default untuk penyederhanaan pengaturan ini. Untuk melakukannya, tambahkan parameter masuk baru: scope=openid profile email https://graph.microsoft.com/.default.

Dengan perubahan ini, saat autentikasi App Service mencoba masuk, layanan tidak lagi meminta izin ke Azure AD Graph. Sebaliknya, ia mendapatkan token untuk Microsoft Graph. Setiap penggunaan token tersebut dari kode aplikasi Anda juga perlu diperbarui, seperti yang dijelaskan dalam Memigrasikan aplikasi Anda dari Azure AD Graph ke Microsoft Graph.

Konten terkait

  • Last updated on