Autentikasi dan otorisasi di Azure App Service dan Azure Functions

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 Azure Active Directory, Facebook, Google, Twitter.

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
Penyedia Koneksi OpenID /.auth/login/<providerName> Masuk OpenID Connect App Service

Saat Anda mengaktifkan autentikasi dan otorisasi 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 secara otomatis diarahkan ke HTTPS, terlepas dari pengaturan konfigurasi Layanan Aplikasi untuk menegakkan 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. Untuk membatasi akses aplikasi hanya ke pengguna yang diautentikasi, atur Tindakan yang harus diambil saat permintaan tidak diautentikasi untuk masuk dengan salah satu penyedia identitas yang dikonfigurasi. Untuk mengautentikasi tetapi tidak membatasi akses, atur Tindakan yang harus diambil ketika permintaan tidak diautentikasi ke "Izinkan permintaan anonim (tanpa tindakan)."

Catatan

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 kode aplikasi Anda.

An architecture diagram showing requests being intercepted by a process in the site sandbox which interacts with identity providers before allowing traffic to the deployed site

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.

Aliran autentikasi

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

  • Tanpa penyedia SDK: Aplikasi ini memberikan federasi masuk 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. Ini juga berlaku untuk aplikasi asli yang menandatangani pengguna dalam menggunakan SDK Aplikasi Seluler klien karena SDK membuka tampilan web untuk menandatangani pengguna dengan autentikasi App Service.
  • Dengan penyedia SDK: Aplikasi menandatangani 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. Kode klien memposting token dari penyedia ke 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 (ditangani secara otomatis oleh SDK klien Aplikasi Seluler).

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

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

Izinkan permintaan yang tidak diautentikasi

Opsi ini menunda otorisasi lalu lintas yang tidak diautentikasi 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. Penolakan ini dapat menjadi tindakan pengalihan ke salah satu penyedia identitas yang dikonfigurasi. Dalam kasus ini, klien browser dialihkan ke /.auth/login/<provider> penyedia yang Anda pilih. Jika permintaan anonim berasal dari aplikasi seluler asli, respons yang dikembalikan adalah HTTP 401 Unauthorized. Anda juga dapat mengonfigurasi penolakan menjadi HTTP 401 Unauthorized atau HTTP 403 Forbidden untuk semua permintaan.

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

Secara default, setiap pengguna di penyewa Microsoft Azure Active Directory Anda dapat meminta token untuk aplikasi Anda dari Microsoft Azure Active Directory. Anda dapat mengonfigurasi aplikasi di Microsoft Azure Active Directory jika Anda ingin membatasi akses ke aplikasi anda ke sekumpulan pengguna yang ditentukan.

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.

Sumber daya lainnya

Sampel: