Autentikasi dan otorisasi di Azure App Service dan Azure Functions

  • Artikel

Azure App Service menyediakan kemampuan autentikasi dan otorisasi bawaan (terkadang disebut sebagai "Auth Mudah"), sehingga Anda dapat masuk ke pengguna dan mengakses data dengan menulis minimal atau tanpa kode di aplikasi web Anda, API RESTful, serta seluler ujung belakang, dan juga Azure Functions. Artikel ini menjelaskan bagaimana Azure App Service membantu menyederhanakan autentikasi dan otorisasi untuk aplikasi Anda.

Mengapa menggunakan autentikasi bawaan?

Anda tidak diharuskan menggunakan fitur ini untuk autentikasi dan otorisasi. Anda dapat menggunakan fitur keamanan yang dipaket dalam kerangka kerja web pilihan Anda, atau Anda dapat menulis utilitas Anda sendiri. Namun, Anda harus memastikan bahwa solusi Anda tetap terbaru dengan pembaruan keamanan, protokol, dan browser terbaru.

Menerapkan solusi aman untuk autentikasi (pengguna masuk) dan otorisasi (menyediakan akses ke data aman) dapat mendapatkan upaya signifikan. Anda harus memastikan untuk mengikuti praktik dan standar terbaik industri, dan menjaga implementasi Anda tetap terbarui. Fitur autentikasi bawaan untuk App Service dan Azure Functions dapat menghemat waktu dan upaya Anda dengan menyediakan autentikasi siap pakai dengan penyedia identitas federasi, memungkinkan Anda untuk fokus pada sisa aplikasi Anda.

  • Azure App Service memungkinkan Anda mengintegrasikan berbagai kemampuan autentikasi ke dalam aplikasi web atau API tanpa menerapkannya sendiri.
  • Ini dibangun langsung ke dalam platform dan tidak memerlukan bahasa tertentu, SDK, keahlian keamanan, atau bahkan kode apa pun untuk digunakan.
  • Anda dapat berintegrasi dengan beberapa penyedia masuk. Misalnya, Microsoft Entra, Facebook, Google, Twitter.

Aplikasi Anda mungkin perlu mendukung skenario yang lebih kompleks seperti integrasi Visual Studio atau persetujuan inkremental. Ada beberapa solusi autentikasi berbeda yang tersedia untuk mendukung skenario ini. Untuk mempelajari lebih lanjut, baca Skenario identitas.

IdP

App Service menggunakan identitas federasi, dimana IdP pihak ketiga mengelola identitas pengguna dan alur autentikasi untuk Anda. IdP berikut ini tersedia secara default:

Penyedia Titik akhir masuk Panduan cara kerja
Platform identitas Microsoft /.auth/login/aad Masuk platform identitas Microsoft App Service
Facebook /.auth/login/facebook Masuk Facebook App Service
Google /.auth/login/google Masuk Google App Service
Twitter /.auth/login/twitter Masuk Twitter App Service
GitHub /.auth/login/github Masuk GitHub App Service
Masuk dengan Apple /.auth/login/apple Masuk App Service Dengan masuk Apple (Pratinjau)
Semua penyedia OpenID Connect /.auth/login/<providerName> Masuk OpenID Connect App Service

Saat Anda mengonfigurasi fitur ini dengan salah satu penyedia ini, titik akhir masuknya tersedia untuk autentikasi pengguna dan untuk validasi token autentikasi dari penyedia. Anda dapat memberi pengguna Anda sejumlah opsi masuk ini.

Pertimbangan untuk menggunakan autentikasi bawaan

Mengaktifkan fitur ini akan menyebabkan semua permintaan ke aplikasi Anda dialihkan secara otomatis ke HTTPS, terlepas dari pengaturan konfigurasi Azure App Service untuk menerapkan HTTPS. Anda dapat menonaktifkan ini dengan pengaturan requireHttps di konfigurasi V2. Namun, kami merekomendasikan untuk tetap menggunakan HTTPS, dan Anda harus memastikan tidak ada token keamanan yang pernah ditransmisikan melalui koneksi HTTP yang tidak aman.

App Service dapat digunakan untuk autentikasi dengan atau tanpa membatasi akses ke konten dan API situs Anda. Pembatasan akses dapat diatur di bagian Pengaturan Autentikasi Autentikasi>aplikasi web Anda. Untuk membatasi akses aplikasi hanya untuk pengguna yang diautentikasi, atur Tindakan yang harus diambil saat permintaan tidak diautentikasi untuk masuk dengan salah satu IdP yang dikonfigurasi. Untuk mengautentikasi tetapi tidak membatasi akses, atur Tindakan yang harus diambil ketika permintaan tidak diautentikasi ke "Izinkan permintaan anonim (tanpa tindakan)."

Penting

Anda harus memberikan setiap pendaftaran aplikasi izin dan persetujuannya sendiri. Hindari berbagi izin antar lingkungan dengan menggunakan pendaftaran aplikasi terpisah untuk slot penyebaran terpisah. Saat menguji kode baru, praktik ini dapat membantu mencegah masalah memengaruhi aplikasi produksi.

Cara kerjanya

Arsitektur fitur

Alur autentikasi

Perilaku otorisasi

Penyimpanan token

Pembuatan log dan pelacakan

Arsitektur fitur

Komponen middleware autentikasi dan otorisasi adalah fitur dari platform yang berjalan pada VM yang sama dengan aplikasi Anda. Ketika diaktifkan, setiap permintaan HTTP masuk melewatinya sebelum ditangani oleh aplikasi Anda.

Diagram arsitektur yang memperlihatkan permintaan disadap oleh proses di situs sandbox yang berinteraksi dengan penyedia identitas sebelum mengizinkan lalu lintas ke situs yang diterapkan

Platform middleware menangani beberapa hal untuk aplikasi Anda:

  • Mengautentikasi pengguna dan klien dengan penyedia identitas yang ditentukan
  • Memvalidasi, menyimpan, dan menyegarkan token OAuth yang dikeluarkan oleh penyedia identitas yang dikonfigurasi
  • Mengelola sesi terautentikasi
  • Masukkan informasi identitas ke header permintaan HTTP

Modul ini berjalan secara terpisah dari kode aplikasi Anda dan dapat dikonfigurasi menggunakan pengaturan Azure Resource Manager atau menggunakan file konfigurasi. Tidak diperlukan SDK, bahasa pemrograman tertentu, atau perubahan pada kode aplikasi Anda.

Fitur arsitektur pada Windows (penyebaran non-kontainer)

Modul autentikasi dan otorisasi berjalan sebagai modul IIS dalam kotak pasir yang sama dengan kode aplikasi Anda. Ketika diaktifkan, setiap permintaan HTTP masuk melewatinya sebelum ditangani oleh aplikasi Anda.

Fitur arsitektur di Linux dan kontainer

Modul autentikasi dan otorisasi berjalan dalam kontainer terpisah, terisolasi dari kode aplikasi Anda. Menggunakan apa yang dikenal sebagai pola Duta besar , ia berinteraksi dengan lalu lintas masuk untuk melakukan fungsi serupa seperti pada Windows. Karena tidak berjalan dalam proses, tidak ada integrasi langsung dengan kerangka bahasa tertentu yang dimungkinkan; namun, informasi relevan yang dibutuhkan aplikasi Anda diteruskan menggunakan header permintaan seperti yang dijelaskan di bawah ini.

Alur autentikasi

Alur autentikasi sama untuk semua penyedia, tetapi berbeda tergantung pada apakah Anda ingin masuk dengan SDK penyedia:

  • Tanpa SDK penyedia: Aplikasi mendelegasikan masuk gabungan ke App Service. Ini biasanya terjadi pada aplikasi browser, yang dapat menyajikan halaman masuk penyedia kepada pengguna. Kode server mengelola proses masuk, sehingga juga disebut aliran yang diarahkan server atau aliran server. Kasus ini berlaku untuk aplikasi browser dan aplikasi seluler yang menggunakan browser yang disematkan untuk autentikasi.
  • Dengan SDK penyedia: Aplikasi memasukkan pengguna ke penyedia secara manual dan kemudian mengirimkan token autentikasi ke App Service untuk validasi. Ini biasanya terjadi pada aplikasi tanpa browser, yang tidak dapat menyajikan halaman masuk penyedia kepada pengguna. Kode aplikasi mengelola proses masuk, sehingga juga disebut aliran yang diarahkan klien atau aliran klien. Kasus ini berlaku untuk REST API, Azure Functions, dan browser JavaScript klien, serta aplikasi browser yang membutuhkan lebih banyak fleksibilitas dalam proses masuk. Ini juga berlaku untuk aplikasi seluler asli yang menandatangani pengguna dalam menggunakan penyedia SDK.

Panggilan dari aplikasi browser tepercaya di App Service ke REST API lain di App Service atau Azure Functions dapat diautentikasi menggunakan alur yang diarahkan server. Untuk informasi selengkapnya, lihat Mengkustomisasi masuk dan keluar.

Tabel di bawah ini memperlihatkan langkah-langkah alur autentikasi.

Langkah Tanpa penyedia SDK Dengan penyedia SDK
1. Masuk pengguna Mengalihkan klien ke /.auth/login/<provider>. Kode klien masuk pengguna langsung dengan SDK penyedia dan menerima token autentikasi. Untuk informasi, lihat dokumentasi penyedia.
2. Pasca-autentikasi Penyedia mengalihkan klien ke /.auth/login/<provider>/callback. Klien kode kirim token dari penyedia ke /.auth/login/<provider> untuk validasi.
3. Membuat sesi terautentikasi App Service menambahkan cookie terautentikasi ke respons. App Service mengembalikan token autentikasinya sendiri ke kode klien.
4. Menyajikan konten yang diautentikasi Klien menyertakan cookie autentikasi dalam permintaan berikutnya (ditangani secara otomatis oleh browser). Kode klien menyajikan token autentikasi di header X-ZUMO-AUTH.

Untuk browser klien, App Service dapat secara otomatis mengarahkan semua pengguna yang tidak diautentikasi ke /.auth/login/<provider>. Anda juga dapat menyajikan pengguna dengan satu atau beberapa /.auth/login/<provider> tautan untuk masuk ke aplikasi Anda menggunakan penyedia pilihan mereka.

Perilaku otorisasi

Penting

Secara default, fitur ini hanya menyediakan autentikasi, bukan otorisasi. Aplikasi Anda mungkin masih perlu membuat keputusan otorisasi, selain pemeriksaan apa pun yang Anda konfigurasi di sini.

Di portal Microsoft Azure, Anda dapat mengonfigurasi App Service dengan sejumlah perilaku saat permintaan masuk tidak diautentikasi. Judul berikut ini menjelaskan opsi.

Akses restrik

  • Izinkan permintaan yang tidak diaauthenticated Opsi ini menuangkan otorisasi lalu lintas yang tidak diaauthenticated ke kode aplikasi Anda. Untuk permintaan terautentikasi, App Service juga meneruskan informasi autentikasi di header HTTP.

    Opsi ini memberikan lebih banyak fleksibilitas dalam menangani permintaan anonim. Misalnya, ini memungkinkan Anda menyajikan beberapa penyedia masuk kepada pengguna Anda. Namun, Anda harus menulis kode.

  • Memerlukan autentikasi Opsi ini akan menolak lalu lintas yang tidak diautentikasi ke aplikasi Anda. Tindakan khusus yang harus diambil ditentukan di bagian Permintaan yang tidak diautentikasi.

    Dengan opsi ini, Anda tidak perlu menulis kode autentikasi apa pun di aplikasi Anda. Otorisasi yang lebih baik, seperti otorisasi khusus peran, dapat ditangani dengan memeriksa klaim pengguna (lihat Akses klaim pengguna).

    Perhatian

    Membatasi akses dengan cara ini berlaku untuk semua panggilan ke aplikasi Anda, yang mungkin tidak diinginkan untuk aplikasi yang menginginkan halaman beranda yang tersedia untuk umum, seperti dalam banyak aplikasi satu halaman.

    Catatan

    Saat menggunakan Penyedia Identitas Microsoft untuk pengguna di organisasi Anda, perilaku defaultnya adalah setiap pengguna di penyewa Microsoft Entra Anda dapat meminta token untuk aplikasi Anda. Anda dapat mengonfigurasi aplikasi di Microsoft Entra jika Anda ingin membatasi akses ke aplikasi Anda ke sekumpulan pengguna yang ditentukan. App Service juga menawarkan beberapa pemeriksaan otorisasi bawaan dasar yang dapat membantu beberapa validasi. Untuk mempelajari selengkapnya tentang otorisasi di Microsoft Entra, lihat Dasar-dasar otorisasi Microsoft Entra.

Permintaan yang tidak diaauthenticated

  • Pengalihan HTTP 302 Ditemukan: direkomendasikan untuk tindakan Pengalihan situs web ke salah satu penyedia identitas yang dikonfigurasi. Dalam kasus ini, klien browser dialihkan ke /.auth/login/<provider> penyedia yang Anda pilih.
  • HTTP 401 Tidak Sah: direkomendasikan untuk API Jika permintaan anonim berasal dari aplikasi seluler asli, respons yang HTTP 401 Unauthorizeddikembalikan adalah . Anda juga dapat mengonfigurasi penolakan menjadi HTTP 401 Unauthorized untuk semua permintaan.
  • HTTP 403 Terlarang Mengonfigurasi penolakan menjadi HTTP 403 Forbidden untuk semua permintaan.
  • HTTP 404 Tidak ditemukan Mengonfigurasi penolakan menjadi HTTP 404 Not found untuk semua permintaan.

Penyimpanan token

App Service menyediakan penyimpanan token bawaan, yang merupakan repositori token yang terkait dengan pengguna aplikasi web, API Anda, atau aplikasi seluler asli. Saat Anda mengaktifkan autentikasi dengan penyedia apa pun, Penyimpanan token ini segera tersedia untuk aplikasi Anda. Jika kode aplikasi Anda perlu mengakses data dari penyedia ini atas nama pengguna, seperti:

  • kirimkan ke linimasa Facebook pengguna yang diautentikasi
  • baca data perusahaan pengguna menggunakan Microsoft Graph API

Anda biasanya harus menulis kode untuk mengumpulkan, menyimpan, dan menyegarkan token ini di aplikasi Anda. Dengan penyimpanan token, Anda cukup mengambil token ketika Anda membutuhkannya dan memberi tahu App Service untuk menyegarkannya ketika mereka menjadi tidak valid.

Token ID, token akses, dan token refresh di-cache untuk sesi yang diautentikasi, dan hanya dapat diakses oleh pengguna terkait.

Jika tidak perlu bekerja dengan token di aplikasi Anda, Anda dapat menonaktifkan peyimpanan token di halamanAutentikasi / Otorisasi aplikasi Anda.

Pencatatan dan pelacakan

Jika Anda mengaktifkan pencatatan aplikasi, Anda akan melihat pelacakan autentikasi dan otorisasi langsung di file log Anda. Jika Anda melihat kesalahan autentikasi yang tidak Anda harapkan, Anda dapat dengan mudah menemukan semua detail dengan melihat log aplikasi yang ada. Jika Anda mengaktifkan pelacakan permintaan yang gagal, Anda dapat melihat dengan tepat peran apa yang mungkin dimainkan modul autentikasi dan otorisasi dalam permintaan yang gagal. Dalam catatan jejak, cari referensi ke modul bernama EasyAuthModule_32/64.

Pertimbangan saat menggunakan Azure Front Door

Saat menggunakan Azure App Service dengan Easy Auth di belakang Azure Front Door atau proksi terbalik lainnya, beberapa hal tambahan harus dipertimbangkan.

  1. Menonaktifkan Penembolokan untuk alur kerja autentikasi

    Lihat Menonaktifkan cache untuk alur kerja autentikasi untuk mempelajari selengkapnya tentang cara mengonfigurasi aturan di Azure Front Door untuk menonaktifkan penembolokan untuk halaman terkait autentikasi dan otorisasi.

  2. Menggunakan titik akhir Front Door untuk pengalihan

    App Service biasanya tidak dapat diakses secara langsung saat diekspos melalui Azure Front Door. Ini dapat dicegah, misalnya, dengan mengekspos App Service melalui Private Link di Azure Front Door Premium. Untuk mencegah alur kerja autentikasi mengalihkan lalu lintas kembali ke App Service secara langsung, penting untuk mengonfigurasi aplikasi untuk mengalihkan kembali ke https://<front-door-endpoint>/.auth/login/<provider>/callback.

  3. Pastikan App Service menggunakan URI pengalihan yang tepat

    Dalam beberapa konfigurasi, App Service menggunakan App Service FQDN sebagai URI pengalihan, bukan Front Door FQDN. Ini akan menyebabkan masalah ketika klien dialihkan ke App Service alih-alih Front Door. Untuk mengubahnya, forwardProxy pengaturan perlu diatur ke untuk Standard membuat App Service menghormati header yang X-Forwarded-Host diatur oleh Azure Front Door.

    Proksi terbalik lainnya seperti Azure Application Gateway atau produk pihak ketiga mungkin menggunakan header yang berbeda dan memerlukan pengaturan forwardProxy yang berbeda.

    Konfigurasi ini tidak dapat dilakukan melalui portal Azure hari ini dan perlu dilakukan melalui az rest:

    Mengekspor pengaturan

    az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

    Memperbarui pengaturan

    Cari

    "httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

    dan pastikan diatur convention ke Standard untuk menghormati header yang X-Forwarded-Host digunakan oleh Azure Front Door.

    Pengaturan impor

    az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

Sumber daya lainnya

Sampel: