Menyesuaikan masuk dan keluar di autentikasi Azure App Service
Artikel ini memperlihatkan kepada Anda cara menyesuaikan masuk dan keluar pengguna sementara menggunakan autentikasi dan otorisasi bawaan di App Service.
Menggunakan banyak penyedia masuk
Konfigurasi portal tidak menawarkan cara turn-key untuk menyajikan beberapa penyedia masuk kepada pengguna Anda (seperti Facebook dan X). Namun, tidak sulit untuk menambahkan fungsionalitas ke aplikasi Anda. Langkah-langkahnya diuraikan sebagai berikut:
Pertama, di halaman Autentikasi / Otorisasi di portal Azure, konfigurasikan setiap penyedia identitas yang ingin Anda aktifkan.
Dalam Tindakan yang diambil saat permintaan tidak diautentikasi, pilih Izinkan permintaan Anonim (tanpa tindakan).
Di halaman masuk, atau bilah navigasi, atau lokasi lain dari aplikasi Anda, tambahkan tautan masuk ke setiap penyedia yang Anda aktifkan ( /.auth/login/<provider>
). Contohnya:
<a href="/.auth/login/aad">Log in with Microsoft Entra</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/x">Log in with X</a>
<a href="/.auth/login/apple">Log in with Apple</a>
Saat pengguna mengklik salah satu tautan, halaman masuk masing-masing terbuka untuk masuk pengguna.
Untuk mengalihkan pengguna pasca masuk ke URL kustom, gunakan post_login_redirect_uri
parameter string kueri (tidak untuk disalahpahami dengan URI Pengalihan di konfigurasi penyedia identitas Anda). Misalnya, untuk menavigasi pengguna ke /Home/Index
setelah masuk, gunakan kode HTML berikut:
<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>
Masuk yang diarahkan klien
Dalam proses masuk yang diarahkan klien, aplikasi memproses masuk pengguna ke penyedia identitas menggunakan SDK khusus penyedia. Kode aplikasi kemudian mengirimkan token autentikasi yang dihasilkan ke App Service untuk validasi (lihat Alur Autentikasi) menggunakan permintaan HTTP POST. Validasi ini sendiri sebenarnya tidak memberi Anda akses ke sumber daya aplikasi yang diinginkan, tetapi validasi yang berhasil akan memberi Anda token sesi yang dapat Anda gunakan untuk mengakses sumber daya aplikasi.
Untuk memvalidasi token penyedia, aplikasi App Service harus terlebih dahulu dikonfigurasi dengan penyedia yang diinginkan. Pada waktu proses, setelah Anda mengambil token autentikasi dari penyedia Anda, posting token ke /.auth/login/<provider>
untuk validasi. Contohnya:
POST https://<appname>.azurewebsites.net/.auth/login/aad HTTP/1.1
Content-Type: application/json
{"id_token":"<token>","access_token":"<token>"}
Format token sedikit bervariasi menurut penyedia. Untuk detailnya, lihat tabel berikut:
Nilai penyedia | Diperlukan dalam badan permintaan | Komentar |
---|---|---|
aad |
{"access_token":"<access_token>"} |
Properti id_token , refresh_token , dan expires_in bersifat opsional. |
microsoftaccount |
{"access_token":"<access_token>"} atau {"authentication_token": "<token>" |
authentication_token lebih disukai daripada access_token . Properti expires_in bersifat opsional. Saat meminta token dari layanan Live, selalu minta ruang lingkup wl.basic . |
google |
{"id_token":"<id_token>"} |
Properti authorization_code bersifat opsional. Memberikan nilai authorization_code akan menambahkan token akses dan token refresh ke penyimpanan token. Ketika ditentukan, authorization_code juga dapat secara opsional disertai dengan properti redirect_uri . |
facebook |
{"access_token":"<user_access_token>"} |
Gunakan token akses pengguna yang valid dari Facebook. |
twitter |
{"access_token":"<access_token>", "access_token_secret":"<access_token_secret>"} |
|
Catatan
Penyedia GitHub untuk autentikasi App Service tidak mendukung rincian masuk dan keluar yang disesuaikan.
Jika token penyedia berhasil divalidasi, API akan kembali dengan authenticationToken
dalam isi respons, yang merupakan token sesi Anda. Untuk mendapatkan informasi selengkapnya tentang klaim pengguna, lihat Bekerja dengan identitas pengguna di autentikasi Azure App Service.
{
"authenticationToken": "...",
"user": {
"userId": "sid:..."
}
}
Setelah Anda memiliki token sesi ini, Anda dapat mengakses sumber daya aplikasi yang dilindungi dengan menambahkan header X-ZUMO-AUTH
ke permintaan HTTP Anda. Contohnya:
GET https://<appname>.azurewebsites.net/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>
Keluar dari sesi
Pengguna dapat memulai keluar dengan mengirim permintaan GET
ke titik akhir /.auth/logout
dari aplikasi. Permintaan GET
melakukan hal berikut:
- Menghapus cookie autentikasi dari sesi saat ini.
- Menghapus token pengguna saat ini dari penyimpanan token.
- Untuk Microsoft Entra dan Google, lakukan keluar sisi server di penyedia identitas.
Berikut adalah tautan keluar sederhana di halaman web:
<a href="/.auth/logout">Sign out</a>
Secara default, keluar yang berhasil mengalihkan klien ke URL /.auth/logout/complete
. Anda bisa mengubah halaman pengalihan pasca-keluar dengan menambahkan parameter kueri post_logout_redirect_uri
. Contohnya:
GET /.auth/logout?post_logout_redirect_uri=/index.html
Disarankan agar Anda mengenkodekan nilai post_logout_redirect_uri
.
Saat menggunakan URL yang sepenuhnya memenuhi syarat, URL harus dihosting di domain yang sama atau dikonfigurasi sebagai URL pengalihan eksternal yang diizinkan untuk aplikasi Anda. Dalam contoh berikut, untuk mengalihkan ke https://myexternalurl.com
yang tidak dihosting di domain yang sama:
GET /.auth/logout?post_logout_redirect_uri=https%3A%2F%2Fmyexternalurl.com
Jalankan perintah berikut ini di Azure Cloud Shell:
az webapp auth update --name <app_name> --resource-group <group_name> --allowed-external-redirect-urls "https://myexternalurl.com"
Mempertahankan fragmen URL
Setelah pengguna masuk ke aplikasi Anda, mereka biasanya ingin diarahkan ke bagian yang sama dari halaman yang sama, seperti /wiki/Main_Page#SectionZ
. Namun, karena fragmen URL (misalnya, #SectionZ
) tidak pernah dikirim ke server, fragmen tersebut tidak dipertahankan secara default setelah masuk OAuth selesai dan dialihkan kembali ke aplikasi Anda. Pengguna kemudian mendapat pengalaman suboptimal saat mereka perlu menavigasi ke jangkar yang diinginkan lagi. Pembatasan ini berlaku untuk semua solusi autentikasi sisi server.
Di autentikasi App Service, Anda dapat mempertahankan fragmen URL di seluruh masuk OAuth. Untuk melakukan ini, atur pengaturan aplikasi bernama WEBSITE_AUTH_PRESERVE_URL_FRAGMENT
ke true
. Anda dapat melakukannya di portal Azure, atau cukup jalankan perintah berikut di Azure Cloud Shell:
az webapp config appsettings set --name <app_name> --resource-group <group_name> --settings WEBSITE_AUTH_PRESERVE_URL_FRAGMENT="true"
Mengatur petunjuk domain akun masuk
Akun Microsoft dan Microsoft Entra memungkinkan Anda masuk dari beberapa domain. Misalnya, Microsoft Account mengizinkan akun outlook.com, live.com, dan hotmail.com. Microsoft Entra memungkinkan sejumlah domain kustom untuk akun masuk. Namun, Anda mungkin ingin mempercepat pengguna Langsung ke halaman masuk Microsoft Entra bermerk Anda sendiri (seperti contoso.com
). Untuk menyarankan nama domain akun masuk, ikuti langkah-langkah ini.
Di https://resources.azure.com, Di bagian atas halaman, pilih Baca/Tulis.
Di browser sebelah kiri, arahkan ke langganan><nama-langganan>resourceGroups><nama grup sumber daya>>situs>Microsoft.Web> ><nama aplikasi>>config>authsettingsV2.
Klik Edit.
Tambahkan array
loginParameters
dengan itemdomain_hint
."identityProviders": { "azureActiveDirectory": { "login": { "loginParameters": ["domain_hint=<domain-name>"], } } }
Klik Put.
Pengaturan ini menambah parameter string kueri domain_hint
ke URL pengalihan log masuk.
Penting
Dimungkinkan bagi klien untuk menghapus parameter domain_hint
setelah menerima URL pengalihan, lalu masuk dengan domain yang berbeda. Jadi, meskipun fungsi ini nyaman, itu bukan fitur keamanan.
Mengotorisasi atau menolak pengguna
Meskipun App Service menangani kasus otorisasi paling sederhana (yaitu menolak permintaan yang tidak diautentikasi), aplikasi Anda mungkin memerlukan perilaku otorisasi yang lebih halus, seperti membatasi akses hanya ke sekelompok pengguna tertentu. Dalam kasus tertentu, Anda perlu menulis kode aplikasi kustom untuk mengizinkan atau menolak akses untuk pengguna yang masuk. Dalam kasus lain, Layanan Aplikasi atau penyedia identitas Anda mungkin dapat membantu tanpa memerlukan perubahan kode.
Tingkat server (khusus aplikasi Windows)
Untuk aplikasi Windows apa pun, Anda dapat menentukan perilaku otorisasi server web IIS, dengan mengedit file Web.config. Aplikasi Linux tidak menggunakan IIS dan tidak dapat dikonfigurasi melalui Web.config.
Navigasikan ke
https://<app-name>.scm.azurewebsites.net/DebugConsole
Di browser file App Service Anda, navigasikan ke site/wwwroot. Jika Web.config tidak ada, buatlah dengan memilih +>File Baru.
Pilih pensil untuk Web.config untuk mengeditnya. Tambah kode konfigurasi berikut dan klik Simpan. Jika Web.config sudah ada, cukup tambah elemen
<authorization>
dengan semua yang ada di dalamnya. Tambahkan akun yang ingin Anda izinkan dalam elemen<allow>
.<?xml version="1.0" encoding="utf-8"?> <configuration> <system.web> <authorization> <allow users="user1@contoso.com,user2@contoso.com"/> <deny users="*"/> </authorization> </system.web> </configuration>
Tingkat penyedia identitas
Penyedia identitas dapat memberi otorisasi turn-key tertentu. Contohnya:
- Anda dapat mengelola akses tingkat perusahaan secara langsung di Microsoft Entra. Untuk mengetahui petunjuknya, lihat Cara menghapus akses pengguna ke aplikasi.
- Untuk Google, proyek Google API yang termasuk dalam suatu organisasi dapat dikonfigurasi untuk mengizinkan akses hanya kepada pengguna di organisasi Anda (lihat halaman dukungan Menyiapkan Google OAuth 2.0).
Tingkat aplikasi
Jika salah satu level lain tidak memberi otorisasi yang Anda butuhkan, atau jika platform atau penyedia identitas Anda tidak didukung, Anda harus menulis kode kustom untuk mengotorisasi pengguna berdasarkan klaim pengguna.