Apa yang baru untuk autentikasi?

Microsoft secara berkala menambahkan serta memodifikasi fitur dan fungsionalitas platform identitas Microsoft untuk meningkatkan keamanan, kegunaan, dan kepatuhan standarnya.

Kecuali dinyatakan lain, perubahan yang dijelaskan di sini hanya berlaku bagi aplikasi yang terdaftar setelah tanggal efektif perubahan yang ditetapkan.

Periksa artikel ini secara berkala untuk mempelajari mengenai:

• Masalah yang diketahui serta perbaikan
• Perubahan protokol
• Fungsionalitas yang tidak digunakan lagi

Agustus 2024

Kredensial Identitas Gabungan sekarang menggunakan pencocokan peka huruf besar/kecil

Tanggal berlaku: September 2024

Protokol terdampak: Federasi identitas beban kerja

Ubah

Sebelumnya, saat mencocokkan Federated Identity Credential (FIC) issuer, , subjectdan audience nilai terhadap issuernilai terkait , , subjectdan audience yang terkandung dalam token yang dikirim ke ID Microsoft Entra oleh IdP eksternal, pencocokan tidak peka huruf besar/kecil digunakan. Untuk memberikan kontrol yang lebih halus kepada pelanggan, kami beralih untuk memberlakukan pencocokan peka huruf besar/kecil.

Contoh tidak valid:

• Subjek token: repo:contoso/contoso-org:ref:refs/heads/main
• Subjek FIC: repo:Contoso/Contoso-Org:ref:refs/heads/main

Kedua nilai subjek ini tidak cocok dengan huruf besar/kecil, sehingga validasi gagal. Mekanisme yang sama diterapkan ke issuer dan audience validasi.

Perubahan ini akan diterapkan pada awalnya ke aplikasi atau identitas terkelola yang dibuat setelah August 14th, 2024. Aplikasi tidak aktif atau identitas terkelola, ditentukan oleh tidak ada permintaan Federasi Identitas Beban Kerja yang dibuat oleh aplikasi tersebut atau identitas terkelola antara periode August 1st, 2024 ke August 31st, 2024, diperlukan untuk menggunakan pencocokan peka huruf besar/kecil mulai September 27th, 2024. Untuk aplikasi aktif, pencocokan peka huruf besar/kecil hadir di kemudian hari untuk dikomunikasikan.

Untuk menyoroti kegagalan dengan lebih baik karena sensitivitas huruf besar/kecil, kami mengubah pesan kesalahan untuk AADSTS700213. Sekarang akan menyatakan;

`AADSTS700213: No matching federated identity record found for presented assertion subject '{subject}'. Please note that matching is done using a case-sensitive comparison. Check your federated identity credential Subject, Audience, and Issuer against the presented assertion.` 

Tempat penampung '{subject}' menyediakan nilai klaim subjek yang terkandung dalam token yang dikirim dari IdP eksternal ke ID Microsoft Entra. Templat kesalahan ini juga digunakan untuk kegagalan yang tidak peka huruf besar/kecil di sekitarnya issuer dan audience validasi. Jika Anda mengalami kesalahan ini, Anda harus menemukan Kredensial Identitas Federasi yang sesuai dengan issuer, , subjectatau audience tercantum dalam kesalahan dan mengonfirmasi bahwa nilai yang sesuai setara dari perspektif peka huruf besar/kecil. Jika ada ketidakcocokan, Anda perlu mengganti nilai , , issueratau saat ini subjectdi FIC dengan audiencenilai , , issueratau subject yang terkandung audience dalam pesan kesalahan.

Juni 2024

Aplikasi harus terdaftar dalam direktori

Tanggal berlaku: Juni 2024

Titik akhir terdampak: v2.0 dan v1.0

Protokol terdampak: Semua alur

Ubah

Sebelumnya, saat mendaftarkan aplikasi menggunakan pengalaman pendaftaran aplikasi Microsoft Entra, jika pengguna masuk dengan akun Microsoft pribadi mereka (MSA), mereka dapat memilih untuk hanya mengaitkan aplikasi dengan akun pribadi mereka. Itu berarti aplikasi tidak akan dikaitkan dengan atau terkandung dalam direktori apa pun (juga disebut sebagai 'penyewa' atau 'organisasi'). Namun, mulai Juni 2024, semua aplikasi harus terdaftar di direktori. Ini bisa menjadi direktori yang sudah ada, atau direktori baru yang dibuat pengguna akun Microsoft pribadi untuk menampung aplikasi Microsoft Entra mereka dan sumber daya Microsoft lainnya. Pengguna dapat dengan mudah membuat direktori baru untuk digunakan untuk tujuan ini dengan bergabung dengan Program Pengembang Microsoft 365 atau mendaftar ke Azure.

Mendaftarkan aplikasi di direktori, alih-alih hanya mengaitkannya dengan akun pribadi, memiliki berbagai manfaat. Ini termasuk:

• Aplikasi yang terdaftar di direktori memiliki lebih banyak fitur yang tersedia untuk mereka, seperti kemampuan untuk menambahkan lebih dari satu pemilik ke aplikasi, dan kemampuan untuk memverifikasi penerbit aplikasi.
• Aplikasi ini terletak di tempat yang sama dengan sumber daya Microsoft lainnya yang digunakan pengembang, seperti sumber daya Azure.
• Aplikasi menerima manfaat ketahanan yang ditingkatkan.

Ini tidak akan memengaruhi aplikasi yang ada, termasuk aplikasi yang ada yang hanya terkait dengan akun pribadi. Hanya kemampuan untuk mendaftarkan aplikasi baru yang akan terpengaruh.

Oktober 2023

Perintah UX RemoteConnect yang Diperbarui

Tanggal berlaku: Oktober 2023

Titik akhir terdampak: v2.0 dan v1.0

Protokol terdampak: RemoteConnect

RemoteConnect adalah alur lintas perangkat yang digunakan untuk Microsoft Authentication Broker dan skenario terkait Microsoft Intune yang melibatkan Token Refresh Utama. Untuk membantu mencegah serangan phishing, alur RemoteConnect menerima bahasa UX yang diperbarui untuk memanggil bahwa perangkat jarak jauh (perangkat yang memulai alur) akan dapat mengakses aplikasi apa pun yang digunakan oleh organisasi Anda setelah berhasil menyelesaikan alur.

Perintah yang muncul akan terlihat seperti ini:

Juni 2023

Kelalaian klaim email dengan pemilik domain yang belum diverifikasi

Tanggal berlaku: Juni 2023

Titik akhir terdampak: v2.0 dan v1.0

Ubah

Untuk aplikasi multi-penyewa, email yang tidak diverifikasi pemilik domain dihilangkan secara default ketika klaim opsional email diminta dalam payload token.

Email dianggap sebagai pemilik domain yang diverifikasi jika:

1. Domain milik penyewa tempat akun pengguna berada, dan admin penyewa telah melakukan verifikasi domain.
2. Email berasal dari Akun Microsoft (MSA).
3. Email tersebut berasal dari akun Google.
4. Email digunakan untuk autentikasi menggunakan alur kode akses satu kali (OTP).

Perlu dicatat juga bahwa akun Facebook dan SAML/WS-Fed tidak memiliki domain terverifikasi.

Mei 2023

Peran administrator Power BI akan diganti namanya menjadi Administrator Fabric.

Tanggal berlaku: Juni 2023

Titik akhir terpengaruh:

• Mencantumkan roleDefinitions - Microsoft Graph v1.0
• Daftar directoryRoles - Microsoft Graph v1.0

Ubah

Peran Administrator Power BI diganti namanya menjadi Administrator Fabric.

Pada 23 Mei 2023, Microsoft mengungkap Microsoft Fabric, yang menyediakan pengalaman integrasi data yang didukung Data Factory, rekayasa data yang didukung Synapse, gudang data, ilmu data, dan pengalaman analitik real-time dan kecerdasan bisnis (BI) dengan Power BI — semuanya dihosting pada solusi SaaS yang berpusat di danau. Administrasi penyewa dan kapasitas untuk pengalaman ini dipusatkan di portal Fabric Admin (sebelumnya dikenal sebagai portal admin Power BI).

Mulai Juni 2023, peran Administrator Power BI diganti namanya menjadi Administrator Fabric agar selaras dengan perubahan cakupan dan tanggung jawab peran ini. Semua aplikasi termasuk MICROSOFT Entra ID, Microsoft Graph API, Microsoft 365, dan GDAP akan mulai mencerminkan nama peran baru selama beberapa minggu.

Sebagai pengingat, kode aplikasi dan skrip Anda tidak boleh membuat keputusan berdasarkan nama peran atau nama tampilan.

Desember 2021

Pengguna Active Directory Federation Services akan melihat lebih banyak permintaan masuk untuk memastikan pengguna masuk yang benar.

Tanggal berlaku: Desember 2021

Titik akhir terpengaruh: Autentikasi Windows Terintegrasi

Protokol terpengaruh: Autentikasi Windows Terintegrasi

Ubah

Hari ini, saat pengguna dikirim ke Active Directory Federation Services untuk melakukan autentikasi, mereka akan masuk tanpa sengaja ke akun apa pun yang sudah memiliki sesi dalam Active Directory Federation Services. Masuk tanpa sengaja ini terjadi meskipun pengguna bermaksud masuk ke akun pengguna yang berbeda. Untuk mengurangi frekuensi proses masuk yang salah ini terjadi, mulai desember MICROSOFT Entra ID akan mengirim prompt=login parameter ke Layanan Federasi Direktori Aktif jika Manajer Akun Web di Windows menyediakan ID login_hint Microsoft Entra selama masuk, yang menunjukkan pengguna tertentu diinginkan untuk masuk.

Ketika persyaratan di atas terpenuhi (WAM digunakan untuk mengirim pengguna ke ID Microsoft Entra untuk masuk, login_hint disertakan, dan instans prompt=loginLayanan Federasi Direktori Aktif untuk domain pengguna mendukung ) pengguna tidak akan masuk secara diam-diam, dan sebaliknya diminta untuk memberikan nama pengguna untuk terus masuk ke Layanan Federasi Direktori Aktif. Jika mereka ingin masuk ke sesi Active Directory Federation Services yang ada, mereka dapat memilih opsi "Lanjutkan sebagai pengguna saat ini" yang ditampilkan di bawah perintah masuk. Jika tidak, mereka dapat melanjutkan dengan nama pengguna yang akan digunakan masuk.

Perubahan ini akan diluncurkan pada Desember 2021 selama beberapa minggu. Hal ini tidak akan mengubah perilaku upaya masuk untuk:

• Aplikasi yang menggunakan IWA secara langsung
• Aplikasi menggunakan OAuth
• Domain yang tidak digabungkan ke instans Active Directory Federation Services

Oktober 2021

Kesalahan 50105 telah diperbaiki untuk tidak mengembalikan interaction_required selama autentikasi interaktif

Tanggal berlaku: Oktober 2021

Titik akhir terdampak: v2.0 dan v1.0

Terkena dampak protokol: Semua alur pengguna untuk aplikasi memerlukan penetapan pengguna

Ubah

Kesalahan 50105 (penunjukan saat ini) muncul saat pengguna yang belum ditetapkan mencoba masuk ke aplikasi yang telah ditandai oleh admin sebagai memerlukan penetapan pengguna. Ini adalah pola kontrol akses yang umum, dan pengguna harus sering menemukan admin untuk meminta penetapan guna membuka blokir akses. Kesalahan tersebut memiliki bug yang akan menyebabkan loop tak terbatas dalam aplikasi yang dikodekan dengan baik yang menangani respons kesalahan interaction_required dengan benar. interaction_required memberi tahu aplikasi untuk melakukan autentikasi interaktif, tetapi bahkan setelah melakukannya, ID Microsoft Entra masih akan mengembalikan interaction_required respons kesalahan.

Skenario kesalahan telah diperbarui, sehingga selama autentikasi non-interaktif (di mana prompt=none digunakan untuk menyembunyikan UX), aplikasi akan diinstruksikan untuk melakukan autentikasi interaktif menggunakan respons kesalahan interaction_required. Dalam autentikasi interaktif berikutnya, ID Microsoft Entra sekarang akan menahan pengguna dan menampilkan pesan kesalahan secara langsung, mencegah terjadinya perulangan.

Sebagai pengingat, kode aplikasi Anda tidak dapat membuat keputusan berdasarkan string kode kesalahan seperti AADSTS50105. Sebagai gantinya, ikuti panduan penanganan kesalahan kami dan gunakan respons autentikasi standar seperti interaction_required dan login_required yang ditemukan di bidang standar error dalam respons. Bidang respons lainnya hanya dimaksudkan untuk konsumsi oleh manusia yang memecahkan masalah mereka.

Anda dapat meninjau teks kesalahan 50105 saat ini dan yang lebih banyak lagi di layanan pencarian kesalahan: https://login.microsoftonline.com/error?code=50105.

AppId Uri dalam aplikasi penyewa tunggal akan memerlukan penggunaan skema default atau domain terverifikasi

Tanggal berlaku: Oktober 2021

Titik akhir terdampak: v2.0 dan v1.0

Protokol terdampak: Semua alur

Ubah

Untuk aplikasi penyewa tunggal, menambahkan atau memperbarui URI AppId memvalidasi bahwa domain dalam URI skema HTTPS tercantum dalam daftar domain terverifikasi di penyewa pelanggan atau bahwa nilai menggunakan skema default (api://{appId}) yang disediakan oleh ID Microsoft Entra. Hal ini dapat mencegah aplikasi dari menambahkan AppId URI jika domain tidak tersedia dalam daftar domain terverifikasi atau nilainya tidak menggunakan skema default. Untuk menemukan informasi selengkapnya tentang domain terverifikasi, lihat dokumentasi domain kustom.

Perubahan tersebut tidak memengaruhi aplikasi yang ada yang menggunakan domain yang belum diverifikasi di URI AppID mereka. Yang divalidasi hanyalah aplikasi baru atau ketika aplikasi yang ada memperbarui URI pengidentifikasi ataupun menambahkan yang baru ke koleksi identifierUri. Pembatasan baru hanya berlaku bagi URI yang ditambahkan ke kumpulan identifierUri aplikasi setelah 15 Oktober 2021. URI AppId yang sudah ada dalam kumpulan identifierUri aplikasi ketika pembatasan mulai berlaku pada 15 Oktober 2021, dan akan terus berfungsi bahkan jika Anda menambahkan URI baru ke koleksi tersebut.

Jika permintaan tidak lolos pemeriksaan validasi, API aplikasi untuk membuat/memperbarui akan mengembalikan 400 badrequest ke klien yang menunjukkan HostNameNotOnVerifiedDomain.

Format URI ID aplikasi berbasis skema API dan HTTP berikut ini didukung. Ganti nilai placeholder seperti yang dijelaskan dalam daftar yang mengikuti tabel.

ID aplikasi yang didukung Format URI	URI ID aplikasi contoh
api://<appId>	api://00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<appId>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<string>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api
api://<string>/<appId>	api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444
https://<tenantInitialDomain>.onmicrosoft.com/<string>	https://contoso.onmicrosoft.com/productsapi
https://<verifiedCustomDomain>/<string>	https://contoso.com/productsapi
https://<string>.<verifiedCustomDomain>	https://product.contoso.com
https://<string>.<verifiedCustomDomain>/<string>	https://product.contoso.com/productsapi

• <appId> - Properti pengidentifikasi aplikasi (appId) objek aplikasi.
• <string> - Nilai string untuk host atau segmen jalur api.
• <tenantId> - GUID yang dihasilkan oleh Azure untuk mewakili penyewa di dalam Azure.
• <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com, ketika <tenantInitialDomain> adalah nama domain awal yang ditentukan oleh pembuat penyewa saat pembuatan penyewa.
• <verifiedCustomDomain> - Domain kustom terverifikasi yang dikonfigurasi untuk penyewa Microsoft Entra Anda.

Agustus 2021

Conditional Access (Akses Bersyarat) hanya akan memicu cakupan yang diminta secara eksplisit

Tanggal berlaku: Agustus 2021, dengan peluncuran bertahap mulai bulan April.

Titik akhir yang terdampak: v2.0

Protokol terdampak : Semua alur yang menggunakan persetujuan dinamis

Aplikasi yang menggunakan persetujuan dinamis hari ini diberi semua izin yang persetujuannya dimiliki, bahkan jika tidak diminta berdasarkan nama dalam parameter scope. Aplikasi yang hanya meminta user.read tetapi dengan persetujuan files.read dapat dipaksa untuk memenuhi persyaratan Akses Bersyarat yang misalnya ditetapkan untuk files.read.

Untuk mengurangi jumlah perintah Akses Bersyarat yang tidak perlu, ID Microsoft Entra mengubah cara cakupan disediakan untuk aplikasi sehingga hanya cakupan yang diminta secara eksplisit yang memicu Akses Bersyarat. Aplikasi yang mengandalkan perilaku Microsoft Entra ID sebelumnya termasuk semua cakupan dalam token--apakah diminta atau tidak--mungkin rusak karena cakupan yang hilang.

Sekarang Aplikasi akan menerima token akses dengan campuran izin: token yang diminta serta izinnya dimiliki, yang tidak memerlukan permintaan Akses Bersyarat. Cakupan token akses tercermin dalam parameter scope di dalam respons token.

Perubahan ini akan dilakukan untuk semua aplikasi kecuali aplikasi dengan dependensi yang diamati pada perilaku ini. Pengembang akan menerima pencapaian jika dikecualikan dari perubahan ini, karena mungkin memiliki dependensi pada perintah Akses Bersyarat tambahan.

Contoh

Aplikasi memiliki persetujuan untuk user.read, files.readwrite, dan tasks.read. files.readwrite memiliki kebijakan Akses Bersyarat yang diterapkan padanya, sementara dua aplikasi lainnya tidak. Jika aplikasi membuat permintaan token untuk scope=user.read, serta pengguna yang saat ini sudah masuk belum melewati kebijakan Akses Bersyarat, token yang dihasilkan akan diperuntukkan untuk izin user.read dan tasks.read. tasks.read dimasukkan karena aplikasi tersebut memiliki izin untuk itu, serta tidak memerlukan kebijakan Akses Bersyarat untuk diberlakukan.

Jika aplikasi kemudian meminta scope=files.readwrite, Conditional Access (Akses Bersyarat) yang diperlukan oleh penyewa akan memicu, memaksa aplikasi untuk menampilkan auth prompt interaktif tempat kebijakan Conditional Access (Akses Bersyarat) dapat dipenuhi. Token yang dikembalikan akan memiliki ketiga cakupan di dalamnya.

Jika aplikasi kemudian membuat satu permintaan terakhir untuk salah satu dari tiga cakupan (misalnya, scope=tasks.read), ID Microsoft Entra akan melihat bahwa pengguna telah menyelesaikan kebijakan Akses Bersyarat yang diperlukan untuk files.readwrite, dan sekali lagi mengeluarkan token dengan ketiga izin di dalamnya.

Juni 2021

UX alur kode perangkat sekarang akan menyertakan perintah konfirmasi aplikasi

Tanggal berlaku: Juni 2021.

Titik akhir terdampak: v2.0 dan v1.0

Protokol yang terpengaruh: Alur kode perangkat

Untuk membantu mencegah serangan phishing, kini alur kode perangkat menyertakan perintah yang memvalidasi pengguna untuk masuk ke aplikasi yang mereka inginkan.

Perintah yang muncul seperti berikut:

2020 Mei

Perbaikan bug: ID Microsoft Entra tidak akan lagi mengodekan URL parameter status dua kali

Tanggal berlaku: Mei 2021

Titik akhir terdampak: v1.0 dan v2.0

Protokol terdampak: Semua alur yang mengunjungi titik akhir /authorize (alur implisit dan alur kode otorisasi)

Bug ditemukan dan diperbaiki dalam respons otorisasi Microsoft Entra. Selama tahap autentikasi /authorize, parameter state dari permintaan akan disertakan dalam respons untuk mempertahankan status aplikasi dan membantu mencegah serangan CSRF. ID Microsoft Entra salah mengodekan state URL parameter sebelum memasukkannya ke dalam respons, di mana id tersebut dikodekan sekali lagi. Ini akan mengakibatkan aplikasi salah menolak respons dari ID Microsoft Entra.

ID Microsoft Entra tidak akan lagi mengodekan dua kali parameter ini, memungkinkan aplikasi untuk mengurai hasil dengan benar. Perubahan ini akan dilakukan untuk semua aplikasi.

Titik akhir Azure Government sedang berubah

Tanggal berlaku: 5 Mei 2020 (selesai Juni 2020)

Titik akhir yang terdampak: Semua

Protokol terdampak: Semua alur

Pada 1 Juni 2018, Otoritas Microsoft Entra resmi untuk Azure Government berubah dari https://login-us.microsoftonline.com menjadi https://login.microsoftonline.us. Perubahan ini juga diterapkan pada Microsoft 365 GCC High dan DoD, yang juga diservis microsoft Entra ID Azure Government. Jika Anda memiliki aplikasi di dalam penyewa Pemerintah AS, Anda harus memperbarui aplikasi Anda untuk membawa masuk pengguna di titik akhir .us.

Pada 5 Mei 2020, MICROSOFT Entra ID akan mulai memberlakukan perubahan titik akhir, memblokir pengguna pemerintah untuk masuk ke aplikasi yang dihosting di penyewa Pemerintah AS menggunakan titik akhir publik (microsoftonline.com). Aplikasi yang terdampak akan mulai melihat kesalahan AADSTS900439 - USGClientNotSupportedOnPublicEndpoint. Kesalahan ini menunjukkan bahwa aplikasi sedang mencoba untuk masuk ke pengguna Pemerintah AS di titik akhir cloud publik. Jika aplikasi Anda berada dalam penyewa cloud publik serta dimaksudkan untuk mendukung pengguna Pemerintah AS, Anda harus memperbarui aplikasi Anda guna mendukungnya secara eksplisit. Ini mungkin memerlukan pembuatan pendaftaran aplikasi baru di cloud Pemerintah AS.

Penegakan perubahan ini akan dilakukan menggunakan peluncuran bertahap berdasarkan seberapa sering pengguna dari Pemerintah AS masuk ke aplikasi - aplikasi yang membawa masuk pengguna Pemerintah AS jarang akan melihat penegakan terlebih dahulu, dan aplikasi yang sering digunakan oleh pengguna Pemerintah AS akan yang terakhir untuk memiliki penegakan yang diterapkan. Kami berharap penerapan selesai di semua aplikasi pada bulan Juni 2020.

Untuk detail lebih lanjut, silakan lihat posting blog Azure Government tentang migrasi ini.

Maret 2020

Kata sandi pengguna akan dibatasi hingga 256 karakter.

Tanggal berlaku: 13 Mei 2020

Titik akhir yang terdampak: Semua

Protokol terdampak: Semua alur pengguna.

Pengguna dengan kata sandi lebih dari 256 karakter yang masuk langsung ke ID Microsoft Entra (bukan IDP federasi, seperti LAYANAN Federasi Direktori Aktif) akan diminta untuk mengubah kata sandi mereka sebelum mereka dapat masuk. Admin mungkin menerima permintaan untuk membantu mengatur ulang kata sandi pengguna.

Kesalahan di dalam log masuk serupa dengan AADSTS 50052: InvalidPasswordExceedsMaxLength.

Pesan: The password entered exceeds the maximum length of 256. Please reach out to your admin to reset the password.

Perbaikan:

Pengguna tidak bisa masuk karena kata sandinya melebihi panjang maksimum yang diizinkan. Pengguna harus menghubungi adminnya untuk mengatur ulang kata sandi. Jika SSPR diaktifkan untuk penyewa, mereka dapat mengatur ulang kata sandi dengan mengikuti tautan "Lupa kata sandi Anda".

Februari 2020

Fragmen kosong akan ditambahkan ke setiap pengalihan HTTP dari titik akhir login.

Tanggal berlaku: 8 Februari 2020

Titik akhir terdampak: Kedua v1.0 dan v2.0

Protokol terdampak: Alur OAuth dan OIDC yang menggunakan response_type=query - hal ini meliputi alur kode otorisasi dalam beberapa kasus, dan alur implisit.

Ketika respons autentikasi dikirim dari login.microsoftonline.com ke aplikasi melalui pengalihan HTTP, layanan akan menambahkan fragmen kosong pada URL balasan. Ini mencegah kelas serangan pengalihan dengan memastikan bahwa browser menghapus fragmen yang ada dalam permintaan autentikasi. Tidak ada aplikasi yang harus memiliki dependensi pada perilaku ini.

Agustus 2019

Semantik formulir POST akan diberlakukan lebih ketat - spasi dan kutipan akan diabaikan

Tanggal berlaku: 2 September 2019

Titik akhir terdampak: Kedua v1.0 dan v2.0

Protokol terdampak: Di mana saja POST digunakan (informasi masuk klien, penukaran kode otorisasi, ROPC, OBO, dan penukaran token refresh)

Mulai minggu yang dimulai pada tanggal 2 September 2019, permintaan autentikasi yang menggunakan metode POST akan divalidasi menggunakan standar HTTP yang lebih ketat. Secara khusus, spasi dan tanda kutip ganda (") tidak akan lagi dihapus dari nilai formulir permintaan. Perubahan ini tidak diharapkan untuk memutus klien yang ada, dan akan memastikan bahwa permintaan yang dikirim ke ID Microsoft Entra ditangani dengan andal setiap saat. Di masa depan (lihat di atas), kami berencana untuk juga menolak parameter duplikat dan mengabaikan BOM di dalam permintaan.

Contoh:

Hari ini, ?e= "f"&g=h diurai secara identik sebagai ?e=f&g=h - menjadi e == f. Dengan perubahan ini, ini sekarang akan diurai sehingga e == "f" - ini tidak mungkin menjadi argumen yang valid, dan permintaan sekarang akan gagal.

Juli 2019

Token khusus aplikasi untuk aplikasi penyewa tunggal hanya diterbitkan jika aplikasi klien ada di penyewa sumber daya

Tanggal berlaku: 26 Mei 2019

Titik akhir terdampak: v1.0 dan v2.0

Protokol terdampak: Kredensial Klien (token khusus aplikasi)

Perubahan keamanan yang mulai berlaku pada 26 Juli 2019 akan mengubah cara token khusus aplikasi (melalui pemberian kredensial klien) dikeluarkan. Sebelumnya, aplikasi diizinkan untuk mendapat token untuk memanggil aplikasi lain, terlepas dari ada tidaknya dalam penyewa atau peran yang disetujui untuk aplikasi itu. Perilaku ini telah diperbarui sehingga untuk sumber daya (terkadang disebut API web) diatur menjadi penyewa tunggal (default), aplikasi klien harus ada dalam penyewa sumber daya. Persetujuan yang ada antara klien dan API tetap tidak diperlukan, serta aplikasi harus tetap melakukan pemeriksaan otorisasi sendiri untuk memastikan bahwa klaim roles ada dan berisi nilai yang diharapkan untuk API.

Pesan kesalahan untuk skenario ini saat ini menyatakan:

The service principal named <appName> was not found in the tenant named <tenant_name>. This can happen if the application has not been installed by the administrator of the tenant.

Untuk memperbaiki masalah ini, gunakan pengalaman Admin Consent (Persetujuan Admin) untuk membuat prinsip layanan aplikasi klien di penyewa Anda, atau buat secara manual. Persyaratan ini memastikan bahwa penyewa telah memberi izin aplikasi untuk beroperasi di dalam penyewa.

Contoh permintaan

https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&... Dalam contoh ini, penyewa sumber daya (otoritas) adalah contoso.com, aplikasi sumber daya adalah aplikasi penyewa tunggal yang disebut gateway.contoso.com/api untuk penyewa Contoso, dan aplikasi klien adalah 00001111-aaaa-2222-bbbb-3333cccc4444. Jika aplikasi klien memiliki perwakilan layanan di dalam Contoso.com, permintaan ini dapat dilanjutkan. Namun, jika tidak, permintaan akan gagal dengan kesalahan di atas.

Namun, jika aplikasi gateway Contoso adalah aplikasi multipenyewa, permintaan akan berlanjut terlepas dari aplikasi klien yang memiliki perwakilan layanan dalam Contoso.com.

URI pengalihan sekarang dapat berisi parameter string kueri

Tanggal berlaku: 22 Juli 2019

Titik akhir terdampak: Kedua v1.0 dan v2.0

Protokol terdampak: Semua alur

Per RFC 6749, aplikasi Microsoft Entra sekarang dapat mendaftar dan menggunakan URI pengalihan (balasan) dengan parameter kueri statis (seperti https://contoso.com/oauth2?idp=microsoft) untuk permintaan OAuth 2.0. URI pengalihan dinamis tetap terlarang karena mewakili risiko keamanan, serta hal ini tidak dapat digunakan untuk menyimpan informasi status di seluruh permintaan autentikasi - untuk itu, gunakan parameter state.

Parameter kueri statis tunduk pada pencocokan string untuk URI pengalihan seperti bagian lain dari URI pengalihan - jika tidak ada string yang terdaftar yang cocok dengan redirect_uri yang didekodekan URI, permintaan akan ditolak. Jika URI ditemukan di pendaftaran aplikasi, seluruh string akan digunakan untuk mengarahkan pengguna, termasuk parameter kueri statis.

Kini (Akhir Juli 2019), UX pendaftaran aplikasi pada portal Microsoft Azure masih memblokir parameter kueri. Namun, Anda dapat mengedit manifes aplikasi secara manual untuk menambah parameter kueri dan mengujinya di aplikasi Anda.

Maret 2019

Klien looping akan terinterupsi

Tanggal berlaku: 25 Maret 2019

Titik akhir terdampak: Kedua v1.0 dan v2.0

Protokol terdampak: Semua alur

Aplikasi klien terkadang dapat melakukan kesalahan, mengeluarkan ratusan permintaan login yang sama dalam waktu singkat. Permintaan ini mungkin atau mungkin tidak berhasil, tetapi semuanya berkontribusi pada pengalaman pengguna yang buruk dan beban kerja yang lebih tinggi untuk IDP, meningkatkan latensi untuk semua pengguna dan mengurangi ketersediaan IDP. Aplikasi ini beroperasi di luar batas penggunaan normal, dan harus diperbarui untuk berperilaku dengan benar.

Klien yang mengeluarkan permintaan duplikat beberapa kali akan dikirimi kesalahan invalid_grant: AADSTS50196: The server terminated an operation because it encountered a loop while processing a request.

Sebagian besar klien tidak perlu mengubah perilaku guna menghindari kesalahan ini. Hanya klien yang salah dikonfigurasi (yang tidak memiliki token peng-cache-an atau yang sudah menunjukkan prompt token) akan terpengaruh oleh kesalahan ini. Klien dilacak berdasarkan per instansi secara lokal (melalui cookie) pada faktor-faktor berikut:

• Petunjuk pengguna, jika ada

• Cakupan atau sumber daya yang diminta

• ID klien

• URI Pengalihan

• Jenis dan mode respons

Aplikasi yang membuat banyak permintaan (15+) dalam waktu singkat (5 menit) akan menerima kesalahan invalid_grant yang menjelaskan bahwa looping telah terjadi. Token yang diminta memiliki masa pakai yang cukup lama (minimum 10 menit, 60 menit secara default), sehingga permintaan berulang selama periode waktu ini tidak diperlukan.

Semua aplikasi harus menangani invalid_grant dengan menampilkan prompt interaktif, alih-alih meminta token secara senyap. Untuk menghindari kesalahan ini, klien harus memastikan bahwa mereka melakukan penembolokan dengan benar pada token yang mereka terima.

Oktober 2018

Kode otorisasi tidak lagi dapat digunakan kembali

Tanggal berlaku: 15 November 2018

Titik akhir terdampak: Kedua v1.0 dan v2.0

Protokol terdampak: Aalur kode

Mulai 15 November 2018, ID Microsoft Entra akan berhenti menerima kode autentikasi yang digunakan sebelumnya untuk aplikasi. Perubahan keamanan ini membantu membawa ID Microsoft Entra sejalan dengan spesifikasi OAuth dan akan diberlakukan pada titik akhir v1 dan v2.

Jika aplikasi Anda menggunakan kembali kode otorisasi untuk mendapatkan token untuk beberapa sumber daya, kami sarankan Anda menggunakan kode untuk mendapatkan token refresh, lalu gunakan token refresh tersebut untuk mendapatkan token tambahan untuk sumber daya lain. Kode otorisasi hanya dapat digunakan satu kali, tetapi token refresh dapat digunakan beberapa kali di beberapa sumber daya. Setiap aplikasi baru yang mencoba menggunakan kembali kode autentikasi selama alur kode OAuth akan mendapat kesalahan invalid_grant.

Untuk informasi selengkapnya tentang token refresh, lihat Menyegarkan token akses. Jika menggunakan ADAL atau MSAL, pustaka akan menanganinya untuk Anda - harap ganti instans kedua dari AcquireTokenByAuthorizationCodeAsync dengan AcquireTokenSilentAsync.

Mei 2018

Token ID tidak bisa digunakan untuk alur OBO

Tanggal: 1 Mei 2018

Titik akhir terdampak: Kedua v1.0 dan v2.0

Protokol terdampak : Alur implisit dan alur atas nama

Setelah 1 Mei 2018, id_tokens tidak bisa digunakan sebagai pernyataan dalam alur OBO untuk aplikasi baru. Token akses harus digunakan sebagai gantinya untuk mengamankan API, bahkan antara klien dan tingkat tengah aplikasi yang sama. Aplikasi yang terdaftar sebelum tanggal 1 Mei 2018 akan terus berfungsi serta dapat menukar id_tokens dengan token akses; namun, pola ini dianggap bukan praktik terbaik.

Untuk mengerjakan perubahan ini, Anda bisa melakukan hal berikut:

1. Buat API web untuk aplikasi Anda, dengan satu atau beberapa cakupan. Titik masuk eksplisit ini akan memungkinkan kontrol dan keamanan yang lebih halus.
2. Dalam manifes aplikasi Anda, di portal Microsoft Azure atau portal pendaftaran aplikasi, pastikan bahwa aplikasi diizinkan untuk mengeluarkan token akses melalui alur implisit. Ini dikendalikan melalui kunci oauth2AllowImplicitFlow.
3. Ketika aplikasi klien Anda meminta id_token melalui response_type=id_token, juga meminta token akses (response_type=token) untuk API web yang dibuat di atas. Dengan demikian, ketika menggunakan titik akhir v2.0, parameter scope harus terlihat mirip dengan api://GUID/SCOPE. Pada titik akhir v1.0, parameter resource harus menjadi URI aplikasi dari API web.
4. Teruskan token akses ini ke tingkat tengah sebagai id_token.