Restriksi dan batasan URI pengalihan (URI balasan)

  • Artikel

URI pengalihan, atau URL balasan, adalah lokasi tempat server otorisasi mengirim pengguna setelah aplikasi berhasil diotorisasi dan diberi kode otorisasi atau token akses. Server otorisasi mengirim kode atau token ke URI pengalihan, jadi penting bagi Anda untuk mendaftarkan lokasi yang benar sebagai bagian dari proses pendaftaran aplikasi.

Model aplikasi Microsoft Entra menentukan batasan ini untuk mengalihkan URI:

  • URI pengalihan harus dimulai dengan skema https. Ada beberapa pengecualian untuk URI pengalihan localhost.

  • URI pengalihan sensitif terhadap kasus dan harus sesuai dengan kasus jalur URL aplikasi yang Anda jalankan. Misalnya, jika aplikasi Anda menyertakan .../abc/response-oidc sebagai bagian dari jalurnya, jangan sebutkan .../ABC/response-oidc di URI balasan. Karena browser web memperlakukan jalur sebagai peka huruf besar/kecil, cookie yang terkait dengan .../abc/response-oidc dapat dikecualikan jika dialihkan ke URL .../ABC/response-oidc yang ukuran hurufnya tidak cocok.

  • URI pengalihan tidak dikonfigurasi dengan segmen jalur dikembalikan dengan garis miring ('/') sebagai tanggapan. Ini hanya berlaku jika mode respons adalah query atau fragment.

    Contoh:

    • https://contoso.com dikembalikan sebagai https://contoso.com/
    • http://localhost:7071 dikembalikan sebagai http://localhost:7071/

  • URI pengalihan yang berisi segmen jalur tidak ditambahkan dengan garis miring di respons.

    Contoh:

    • https://contoso.com/abc dikembalikan sebagai https://contoso.com/abc
    • https://contoso.com/abc/response-oidc dikembalikan sebagai https://contoso.com/abc/response-oidc

  • URI pengalihan tidak mendukung karakter khusus - ! $ ' ( ) , ;

Jumlah maksimum URI pengalihan

Tabel ini memperlihatkan jumlah maksimum URI pengalihan yang dapat Anda tambahkan ke pendaftaran aplikasi di platform identitas Microsoft.

Akun yang sedang dimasuki Jumlah maksimum URI pengalihan Deskripsi
Akun kerja atau sekolah Microsoft di penyewa Microsoft Entra organisasi mana pun 256 Bidang signInAudience dalam manifes aplikasi diatur ke AzureADMyOrg atau AzureADMultipleOrgs
Akun Microsoft pribadi dan akun kantor dan sekolah 100 Bidang signInAudience dalam manifes aplikasi diatur ke AzureADandPersonalMicrosoftAccount

Jumlah maksimum URI pengalihan tidak dapat dinaikkan karena alasan keamanan. Jika skenario Anda memerlukan lebih banyak URI pengalihan daripada jumlah maksimum yang diizinkan, pertimbangkan pendekatan parameter status berikut sebagai solusinya.

Panjang maksimum URI

Anda dapat menggunakan maksimal 256 karakter untuk setiap URI pengalihan yang Anda tambahkan ke pendaftaran aplikasi.

Alihkan URI dalam aplikasi vs. objek perwakilan layanan

  • Selalu tambahkan URI pengalihan ke objek aplikasi saja.
  • Jangan menambahkan pengalihan nilai URI ke prinsip layanan karena nilai-nilai ini dapat dihapus ketika objek utama layanan disinkronkan dengan objek aplikasi. Hal ini dapat terjadi karena setiap operasi pembaruan yang memicu sinkronisasi antara dua objek.

Dukungan parameter kueri dalam URI pengalihan

Parameter kueri diizinkan dalam URI pengalihan untuk aplikasi yang hanya memasukkan pengguna dengan akun kerja atau sekolah.

Parameter kueri tidak diizinkan dalam URI pengalihan untuk pendaftaran aplikasi apa pun yang dikonfigurasi untuk memasukkan pengguna dengan akun Microsoft pribadi seperti Outlook.com (Hotmail), Messenger, OneDrive, MSN, Xbox Live, atau Microsoft 365.

Audiens kredensial masuk pendaftaran aplikasi Mendukung parameter kueri dalam URI pengalihan
Khusus akun dalam direktori organisasi (khusus Contoso - Penyewa tunggal)
Akun di direktori organisasi apa pun (Direktori Microsoft Entra apa pun - Multipenyewa)
Akun di direktori organisasi apa pun (Direktori Microsoft Entra apa pun - Multipenyewa) dan akun Microsoft pribadi (misalnya Skype, Xbox)
Khusus akun Microsoft pribadi

Skema yang didukung

HTTPS: Skema HTTPS (https://) didukung untuk semua URI pengalihan berbasis HTTP.

HTTP: Skema HTTP (http://) didukung hanya untuk localhost URI dan hanya boleh digunakan selama pengembangan dan pengujian aplikasi lokal aktif.

Contoh URI pengalihan Validitas
https://contoso.com Sah
https://contoso.com/abc/response-oidc Sah
https://localhost Sah
http://contoso.com/abc/response-oidc Tidak valid
http://localhost Sah
http://localhost/abc Sah

Pengecualian localhost

Per RFC 8252 bagian 8.3 dan 7.3, "loopback" atau "localhost" URI pengalihan dilengkapi dengan dua pertimbangan khusus:

  1. Skema URI http dapat diterima karena pengalihan tidak pernah meninggalkan perangkat. Dengan demikian, kedua URI ini dapat diterima:
    • http://localhost/myApp
    • https://localhost/myApp
  2. Karena rentang port sementara yang sering diperlukan oleh aplikasi asli, komponen port (misalnya, :5001 atau :443) diabaikan untuk tujuan mencocokkan URI pengalihan. Akibatnya, semua URI ini dianggap setara:
    • http://localhost/MyApp
    • http://localhost:1234/MyApp
    • http://localhost:5000/MyApp
    • http://localhost:8080/MyApp

Dari sudut pandang pengembangan, ini berarti beberapa hal:

  • Jangan mendaftarkan beberapa URI pengalihan saat hanya port yang berbeda. Server login akan memilih satu yang mana saja dan menggunakan perilaku yang terkait dengan URI pengalihan itu (misalnya, apakah jenis pengalihan web, native, atau spa).

    Ini sangat penting ketika Anda ingin menggunakan alur autentikasi yang berbeda dalam pendaftaran aplikasi yang sama, misalnya pemberian kode otorisasi dan alur implisit. Untuk mengaitkan perilaku respons yang benar dengan setiap URI pengalihan, server login harus dapat membedakan antara URI pengalihan dan tidak dapat melakukannya ketika hanya port yang berbeda.

  • Untuk mendaftarkan beberapa URI pengalihan pada localhost untuk menguji alur yang berbeda selama pengembangan, bedakan menggunakan komponen jalur dari URI. Misalnya, http://localhost/MyWebApp tidak cocok dengan http://localhost/MyNativeApp.

  • Alamat loopback IPv6 ([::1]) saat ini tidak didukung.

Lebih menyukai 127.0.0.1 daripada localhost

Untuk mencegah aplikasi Anda rusak oleh firewall yang salah dikonfigurasi atau antarmuka jaringan yang diubah namanya, gunakan alamat loopback literal IP 127.0.0.1 di URI pengalihan Anda, alih-alih localhost. Contohnya, https://127.0.0.1.

Namun, Anda tidak dapat menggunakan kotak teks Alihkan URI di portal Microsoft Azure untuk menambah URI pengalihan berbasis loopback yang menggunakan skema http:

Error dialog in Azure portal showing disallowed http-based loopback redirect URI

Untuk menambah URI pengalihan yang menggunakan skema http dengan alamat loopback 127.0.0.1, Anda saat ini harus memodifikasi atribut replyUrlsWithType dalam manifes aplikasi.

Pembatasan kartubebas dalam URI pengalihan

URI kartubebas seperti https://*.contoso.com mungkin tampak nyaman, tetapi harus dihindari karena implikasi keamanan. Menurut spesifikasi OAuth 2.0 (bagian 3.1.2 dari RFC 6749), URI titik akhir pengalihan harus merupakan URI absolut. Dengan demikian, ketika URI kartubebas yang dikonfigurasi cocok dengan URI pengalihan, string kueri dan fragmen dalam URI pengalihan dilucuti.

Kartubebas URI saat ini tidak didukung dalam pendaftaran aplikasi yang dikonfigurasi untuk masuk ke akun Microsoft pribadi dan akun kantor atau sekolah. URI wildcard diizinkan, namun, untuk aplikasi yang dikonfigurasi untuk masuk hanya ke akun kerja atau sekolah di penyewa Microsoft Entra organisasi.

Untuk menambah UEI pengalihan dengan kartubebas ke pendaftaran aplikasi yang membawa masuk ke akun kantor atau sekolah, gunakan editor manifes aplikasi di Pendaftaran aplikasi di portal Microsoft Azure. Meskipun memungkinkan untuk mengatur URI pengalihan dengan kartubebas menggunakan editor manifes, kami sangat menyarankan Anda mematuhi bagian 3.1.2 RFC 6749. dan hanya menggunakan URI absolut.

Jika skenario Anda memerlukan lebih banyak URI pengalihan daripada batas maksimum yang diizinkan, pertimbangkan pendekatan parameter status berikut alih-alih menambah URI pengalihan kartubebas.

Menggunakan parameter status

Jika Anda memiliki beberapa subdomain dan skenario Anda mengharuskan bahwa, setelah autentikasi berhasil, Anda mengalihkan pengguna ke halaman yang sama dari tempanya memulai, menggunakan parameter status mungkin berguna.

Dalam pendekatan ini:

  1. Buat URI pengalihan "bersama" per aplikasi untuk memproses token keamanan yang Anda terima dari titik akhir otorisasi.
  2. Aplikasi Anda dapat mengirim parameter khusus aplikasi (seperti URL subdomain tempat pengguna berasal atau apa pun seperti informasi branding) di dalam parameter status. Saat menggunakan parameter status, jaga terhadap perlindungan CSRF seperti yang ditentukan dalam bagian 10.12 RFC 6749.
  3. Parameter khusus aplikasi akan mencakup semua informasi yang diperlukan untuk aplikasi untuk memberi pengalaman yang benar bagi pengguna, yaitu, membangun status aplikasi yang sesuai. Titik akhir otorisasi Microsoft Entra menghapus HTML dari parameter status jadi pastikan Anda tidak meneruskan konten HTML dalam parameter ini.
  4. Ketika MICROSOFT Entra ID mengirim respons ke URI pengalihan "bersama", id tersebut akan mengirim parameter status kembali ke aplikasi.
  5. Aplikasi kemudian dapat menggunakan nilai dalam parameter status untuk menentukan URL mana yang akan dikirim lebih lanjut kepada pengguna. Pastikan Anda memvalidasi perlindungan CSRF.

Peringatan

Pendekatan ini memungkinkan klien yang disusupi untuk memodifikasi parameter tambahan yang dikirim dalam parameter status, sehingga mengarahkan pengguna ke URL yang berbeda, yang merupakan ancaman pengalihan terbuka yang dijelaskan dalam RFC 6819. Oleh karena itu, klien harus melindungi parameter ini dengan mengenkripsi keadaan atau memverifikasinya dengan cara lain, seperti memvalidasi nama domain di URI pengalihan terhadap token.

Langkah berikutnya

Pelajari Manifes aplikasi pendaftaran aplikasi.