Kimlik doğrulamasıyla ilgili yenilikler

Microsoft, güvenlik, kullanılabilirlik ve standartların uyumluluğunu geliştirmek için Microsoft kimlik platformu özelliklerini ve işlevlerini düzenli aralıklarla ekler ve değiştirir.

Aksi belirtilmediği sürece, burada açıklanan değişiklikler yalnızca değişikliğin belirtilen geçerlilik tarihinden sonra kaydedilen uygulamalar için geçerlidir.

Aşağıdakiler hakkında bilgi edinmek için bu makaleyi düzenli olarak gözden geçirin:

• Bilinen sorunlar ve düzeltmeler
• Protokol değişiklikleri
• Kullanım dışı işlevsellik

Ağustos 2024

Federasyon Kimliği Kimlik Bilgileri artık büyük/küçük harfe duyarlı eşleştirme kullanıyor

Geçerlilik tarihi: Eylül 2024

Protokol etkilendi: İş yükü kimliği federasyonu

Değiştir

Daha önce, Federasyon Kimliği Kimlik Bilgileri (FIC) issuer, subjectve audience değerleri, karşılık gelen issuer, subjectve audience belirteçte yer alan değerlerle eşleştirilirken dış IdP tarafından Microsoft Entra Id'ye gönderilirken büyük/küçük harfe duyarsız eşleştirme kullanılıyordu. Müşterilere daha ayrıntılı denetim sağlamak için büyük/küçük harfe duyarlı eşleştirmeyi zorunlu kılmaya geçiyoruz.

Geçersiz örnek:

• Belirteç konusu: repo:contoso/contoso-org:ref:refs/heads/main
• FIC konusu: repo:Contoso/Contoso-Org:ref:refs/heads/main

Bu iki konu değeri büyük/küçük harfe duyarlı olarak eşleşmediğinden doğrulama başarısız olur. Ve doğrulamasına issueraudience aynı mekanizma uygulanır.

Bu değişiklik başlangıçta uygulamasından sonra August 14th, 2024oluşturulan uygulamalara veya yönetilen kimliklere uygulanır. ile arasında August 1st, 2024August 31st, 2024söz konusu uygulama veya yönetilen kimlik tarafından yapılan sıfır İş Yükü Kimliği Federasyon isteğiyle belirlenen etkin olmayan uygulamalar veya yönetilen kimlikler, ile başlayan September 27th, 2024büyük/küçük harfe duyarlı eşleştirmeyi kullanmak için gereklidir. Etkin uygulamalar için büyük/küçük harfe duyarlı eşleştirme, daha sonraki bir tarihte iletilecek şekilde gelir.

Büyük/küçük harf duyarlılığı nedeniyle oluşan hataları daha iyi vurgulamak için hata iletisini AADSTS700213için yenileyeceğiz. Şimdi belirtecektir;

`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.` 

Yer tutucu '{subject}' , dış IdP'den Microsoft Entra Kimliği'ne gönderilen belirteçte yer alan konu talebi değerini sağlar. Bu hata şablonu, çevresindeki issuer büyük/küçük harfe duyarlı olmayan hatalar ve audience doğrulama için de kullanılır. Bu hatayla karşılaşırsanız, hatada listelenen veya issuer öğesine karşılık gelen subjectaudienceFederasyon Kimliği Kimlik Bilgilerini bulmanız ve karşılık gelen değerlerin büyük/küçük harfe duyarlı bir perspektiften eşdeğer olduğunu onaylamanız gerekir. Uyuşmazlık varsa FIC'deki geçerli issuer, subjectveya audience değerini hata iletisinde yer alan , issuerveya subject değeriyle audiencedeğiştirmeniz gerekir.

Haziran 2024

Uygulamaların bir dizine kaydedilmesi gerekir

Geçerlilik tarihi: Haziran 2024

Etkilenen uç noktalar: v2.0 ve v1.0

Protokol etkilendi: Tüm akışlar

Değiştir

Daha önce, Microsoft Entra uygulama kayıtları deneyimini kullanarak bir uygulamayı kaydederken, kullanıcı kişisel Microsoft hesabıyla (MSA) oturum açtıysa, uygulamayı yalnızca kişisel hesabıyla ilişkilendirmeyi seçebilirdi. Bu, uygulamanın herhangi bir dizinle ('kiracı' veya 'kuruluş' olarak da adlandırılır) ilişkilendirilmeyeceğini veya bu dizinde yer almayacağını gösterir. Ancak Haziran 2024'den itibaren tüm uygulamaların bir dizine kaydedilmesi gerekir. Bu, mevcut bir dizin veya kişisel Microsoft hesabı kullanıcısının Microsoft Entra uygulamalarını ve diğer Microsoft kaynaklarını barındıracak şekilde oluşturduğu yeni bir dizin olabilir. Kullanıcılar, Microsoft 365 Geliştirici Programı'na katılarak veya Azure'a kaydolarak bu amaçla kullanmak üzere kolayca yeni bir dizin oluşturabilir.

Bir uygulamayı yalnızca kişisel bir hesapla ilişkilendirmek yerine dizine kaydetmenin çeşitli avantajları vardır. Bu modüller şunlardır:

• Bir dizine kayıtlı uygulamalar, uygulamaya birden fazla sahip ekleme ve uygulamayı yayımcı olarak doğrulama gibi daha fazla özelliğe sahiptir.
• Uygulama, azure kaynakları gibi geliştiricinin kullandığı diğer Microsoft kaynaklarıyla aynı yerde bulunur.
• Uygulama gelişmiş dayanıklılık avantajları alır.

Bu, yalnızca kişisel bir hesapla ilişkili mevcut uygulamalar da dahil olmak üzere mevcut uygulamaları etkilemez. Yalnızca yeni uygulamaları kaydetme özelliği etkilenir.

Ekim 2023

RemoteConnect UX İstemi güncelleştirildi

Geçerlilik tarihi: Ekim 2023

Etkilenen uç noktalar: v2.0 ve v1.0

Protokol etkilendi: RemoteConnect

RemoteConnect, Birincil Yenileme Belirteçleri içeren Microsoft Kimlik Doğrulama Aracısı ve Microsoft Intune ile ilgili senaryolar için kullanılan cihazlar arası bir akıştır. Kimlik avı saldırılarını önlemeye yardımcı olmak için RemoteConnect akışı, uzak cihazın (akışı başlatan cihaz) akışın başarıyla tamamlanmasının ardından kuruluşunuz tarafından kullanılan tüm uygulamalara erişebileceğini belirten güncelleştirilmiş UX dili alıyor.

Görüntülenen istem şuna benzer olacaktır:

Haziran 2023

Onaylanmamış bir etki alanı sahibiyle e-posta taleplerinin atilmesi

Geçerlilik tarihi: Haziran 2023

Etkilenen uç noktalar: v2.0 ve v1.0

Değiştir

Çok kiracılı uygulamalarda, etki alanı sahibi doğrulanmamış e-postalar, isteğe bağlı email talep bir belirteç yükünde istendiğinde varsayılan olarak atlanır.

E-postanın etki alanı sahibi olduğu kabul edilir ve şu durumda doğrulanır:

1. Etki alanı, kullanıcı hesabının bulunduğu kiracıya aittir ve kiracı yöneticisi etki alanı doğrulamasını yapmıştır.
2. E-posta bir Microsoft Hesabından (MSA) alınır.
3. E-posta bir Google hesabından alınmıştı.
4. E-posta, tek seferlik geçiş kodu (OTP) akışı kullanılarak kimlik doğrulaması için kullanıldı.

Facebook ve SAML/WS-Fed hesaplarında doğrulanmış etki alanları olmadığı da belirtilmelidir.

Mayıs 2023

Power BI yönetici rolü Doku Yöneticisi olarak yeniden adlandırılacaktır.

Geçerlilik tarihi: Haziran 2023

Etkilenen uç noktalar:

• RoleDefinitions listesi - Microsoft Graph v1.0
• List directoryRoles - Microsoft Graph v1.0

Değiştir

Power BI Yöneticisi rolü Doku Yöneticisi olarak yeniden adlandırılır.

Microsoft, 23 Mayıs 2023'te Power BI ile Data Factory destekli veri tümleştirme deneyimi, Synapse destekli veri mühendisliği, veri ambarı, veri bilimi ve gerçek zamanlı analiz deneyimleri ve iş zekası (BI) sağlayan Microsoft Fabric'i kullanıma sunmşu. Bunların tümü göl merkezli bir SaaS çözümünde barındırılıyor. Bu deneyimler için kiracı ve kapasite yönetimi, Doku Yöneticisi portalında (önceki adıyla Power BI yönetici portalı) merkezidir.

Haziran 2023'den itibaren Power BI Yöneticisi rolü, bu rolün değişen kapsamı ve sorumluluğuyla uyumlu olacak şekilde Doku Yöneticisi olarak yeniden adlandırıldı. Microsoft Entra ID, Microsoft Graph API'leri, Microsoft 365 ve GDAP dahil olmak üzere tüm uygulamalar birkaç hafta boyunca yeni rol adını yansıtmaya başlayacaktır.

Hatırlatmak gerekirse, uygulama kodunuz ve betikleriniz rol adına veya görünen ada göre karar vermemelidir.

Aralık 2021

AD FS kullanıcıları, doğru kullanıcının oturum açtığından emin olmak için daha fazla oturum açma istemi görür.

Geçerlilik tarihi: Aralık 2021

Etkilenen uç noktalar: Tümleşik Windows Kimlik Doğrulaması

Protokol etkilendi: Tümleşik Windows Kimlik Doğrulaması

Değiştir

Bugün, bir kullanıcı kimlik doğrulaması için AD FS'ye gönderildiğinde, AD FS ile oturum açmış olan tüm hesaplarda sessizce oturum açılır. Kullanıcı farklı bir kullanıcı hesabında oturum açmayı amaçlasa bile sessiz oturum açma gerçekleşir. Bu yanlış oturum açmanın oluşma sıklığını azaltmak için, Windows'daki Web Hesabı Yöneticisi oturum açma sırasında Microsoft Entra Id prompt=login a sağlıyorsa, Aralık ayından itibaren Microsoft Entra Id parametresini AD FS'ye gönderir login_hint ve bu da belirli bir kullanıcının oturum açmak için istendiğini gösterir.

Yukarıdaki gereksinimler karşılandığında (WAM kullanıcıyı oturum açmak üzere Microsoft Entra Id'ye göndermek için kullanılır, bir login_hint eklenir ve kullanıcının etki alanı için AD FS örneği desteklenir prompt=login) kullanıcı sessizce oturum açmaz ve bunun yerine AD FS'de oturum açmaya devam etmek için bir kullanıcı adı sağlamasını ister. Mevcut AD FS oturumlarında oturum açmak isterlerse, oturum açma isteminin altında görüntülenen "Geçerli kullanıcı olarak devam et" seçeneğini belirleyebilirler. Aksi takdirde, oturum açmayı amaçladıkları kullanıcı adıyla devam edebilir.

Bu değişiklik, birkaç hafta boyunca Aralık 2021'de kullanıma sunulacaktır. Oturum açma davranışını değiştirmez:

• Doğrudan IWA kullanan uygulamalar
• OAuth kullanan uygulamalar
• AD FS örneğine federasyon olmayan etki alanları

Ekim 2021

50105 hatası, etkileşimli kimlik doğrulaması sırasında döndürülmeyecek interaction_required şekilde düzeltildi

Geçerlilik tarihi: Ekim 2021

Etkilenen uç noktalar: v2.0 ve v1.0

Protokol etkilendi: Kullanıcı ataması gerektiren uygulamalar için tüm kullanıcı akışları

Değiştir

Atanmamış bir kullanıcı, yöneticinin kullanıcı ataması gerektirdiğini işaretlediği bir uygulamada oturum açmaya çalıştığında hata 50105 (geçerli atama) ortaya çıkar. Bu yaygın bir erişim denetimi düzenidir ve kullanıcıların genellikle erişimin engelini kaldırmak için atama istemek için bir yönetici bulması gerekir. Hata, hata yanıtını doğru işleyen iyi kodlanmış uygulamalarda sonsuz döngülere neden olan bir hataya interaction_required neden oldu. interaction_required bir uygulamaya etkileşimli kimlik doğrulaması gerçekleştirmesini söyler, ancak bunu yaptıktan sonra bile Microsoft Entra Id yine de bir interaction_required hata yanıtı döndürür.

Hata senaryosu güncelleştirildi, böylece etkileşimli olmayan kimlik doğrulaması sırasında ( prompt=none UX'yi gizlemek için kullanılır), uygulamaya bir interaction_required hata yanıtı kullanarak etkileşimli kimlik doğrulaması gerçekleştirmesi istenir. Sonraki etkileşimli kimlik doğrulamasında, Microsoft Entra Id artık kullanıcıyı tutar ve bir döngünün oluşmasını önleyen bir hata iletisini doğrudan gösterir.

Hatırlatmak gerekirse, uygulama kodunuz gibi AADSTS50105hata kodu dizelerine dayalı kararlar almamalıdır. Bunun yerine, hata işleme kılavuzumuzu izleyin ve yanıttaki error kullanın. Diğer yanıt alanları yalnızca sorunlarını gideren insanlar tarafından kullanılmak üzere tasarlanmıştır.

Hata arama hizmetinde 50105 hatasının geçerli metnini ve daha fazlasını gözden geçirebilirsiniz: https://login.microsoftonline.com/error?code=50105.

Tek kiracılı uygulamalarda AppId Uri'sinin varsayılan düzenin veya doğrulanmış etki alanlarının kullanılması gerekir

Geçerlilik tarihi: Ekim 2021

Etkilenen uç noktalar: v2.0 ve v1.0

Protokol etkilendi: Tüm akışlar

Değiştir

Tek kiracılı uygulamalar için AppId URI'sinin eklenmesi veya güncelleştirilmesi, HTTPS şeması URI'sindeki etki alanının müşteri kiracısında doğrulanmış etki alanı listesinde listelendiğini veya değerin Microsoft Entra Id tarafından sağlanan varsayılan düzeni (api://{appId}) kullandığını doğrular. Bu, etki alanı doğrulanmış etki alanı listesinde değilse veya değer varsayılan düzeni kullanmıyorsa uygulamaların AppId URI'sini eklemesini engelleyebilir. Doğrulanmış etki alanları hakkında daha fazla bilgi edinmek için özel etki alanları belgelerine bakın.

Bu değişiklik, AppID URI'sinde doğrulanmamış etki alanları kullanan mevcut uygulamaları etkilemez. Yalnızca yeni uygulamaları doğrular veya var olan bir uygulama bir tanımlayıcı URI'sini güncelleştirdiğinde veya identifierUri koleksiyonuna yeni bir tane eklediğinde doğrular. Yeni kısıtlamalar yalnızca 15 Ekim 2021'de uygulamanın identifierUris koleksiyonuna eklenen URI'ler için geçerlidir. Kısıtlama 15 Ekim 2021'de geçerli olduğunda uygulamanın identifierUris koleksiyonunda bulunan AppId URI'leri, bu koleksiyona yeni URI'ler ekleseniz bile çalışmaya devam eder.

Bir istek doğrulama denetiminde başarısız olursa, oluşturma/güncelleştirme için uygulama API'si istemciye HostNameNotOnVerifiedDomain değerini belirten bir 400 badrequest döndürür.

Aşağıdaki API ve HTTP şeması tabanlı uygulama kimliği URI biçimleri desteklenir. Yer tutucu değerlerini, tablodan sonraki listede açıklandığı gibi değiştirin.

Desteklenen uygulama kimliği URI biçimleri	Örnek uygulama kimliği URI'leri
<api:// appId>	api://00001111-aaaa-2222-bbbb-3333cccc4444
<api:// tenantId>/<appId>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444
<api:// tenantId>/<dize>	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> - Uygulama nesnesinin uygulama tanımlayıcısı (appId) özelliği.
• <string> - Konağın veya api yolu kesiminin dize değeri.
• <tenantId> - Azure'da kiracıyı temsil etmek için Azure tarafından oluşturulan BIR GUID.
• - > ; burada< tenantInitialDomain>, kiracı oluşturma sırasında kiracı oluşturucusunun belirttiği ilk etki alanı adıdır.
• <verifiedCustomDomain> - Microsoft Entra kiracınız için yapılandırılmış doğrulanmış bir özel etki alanı .

Ağustos 2021

Koşullu Erişim yalnızca açıkça istenen kapsamlar için tetiklenir

Geçerlilik tarihi: Ağustos 2021, nisan ayında başlayan aşamalı dağıtım.

Etkilenen uç noktalar: v2.0

Protokol etkilendi: Dinamik onay kullanan tüm akışlar

Bugün dinamik onay kullanan uygulamalara, parametrede scope ada göre istenmese bile, izinlerine sahip oldukları tüm izinler verilir. Yalnızca user.read istekte bulunan ancak onayı files.read olan bir uygulama, örneğin için files.readatanan Koşullu Erişim gereksinimini geçirmeye zorlanabilir.

Gereksiz Koşullu Erişim istemlerinin sayısını azaltmak için, Microsoft Entra ID kapsamların uygulamalara sunulma şeklini değiştirerek koşullu erişimi yalnızca açıkça istenen kapsamların tetiklemesini sağlar. Microsoft Entra Id'nin belirteçteki tüm kapsamları dahil etme davranışına (istenen veya olmayan) dayanan uygulamalar eksik kapsamlar nedeniyle bozulabilir.

Uygulamalar artık koşullu erişim istemleri gerektirmeyen izinlerin karışımına sahip erişim belirteçleri alır: istenen belirteçler ve onay verdikleri belirteçler. Belirteç için erişim kapsamı, belirteç yanıtının scope parametresine yansıtılır.

Bu değişiklik, bu davranışa bağımlılığı gözlemlenen uygulamalar dışında tüm uygulamalar için yapılır. Geliştiriciler, ek Koşullu Erişim istemlerine bağımlılığı olabileceğinden, bu değişiklikten muaf tutulurlarsa yardım alır.

Örnekler

Bir uygulamanın , user.readve files.readwriteiçin tasks.readonayı vardır. files.readwrite bu ilkeye Koşullu Erişim ilkeleri uygulanırken, diğer ikisi uygulanmaz. Bir uygulama için scope=user.readbelirteç isteğinde bulunursa ve şu anda oturum açmış olan kullanıcı herhangi bir Koşullu Erişim ilkesi geçirmediyse, sonuçta elde edilen belirteç ve user.read izinleri için tasks.read olur. tasks.read dahil edilir çünkü uygulamanın onayı vardır ve bir Koşullu Erişim ilkesinin zorunlu kılınmasını gerektirmez.

Uygulama daha sonra isteğinde bulunursa scope=files.readwrite, kiracı tarafından gereken Koşullu Erişim tetiklenir ve uygulamayı Koşullu Erişim ilkesinin karşılanabileceği etkileşimli bir kimlik doğrulama istemi göstermeye zorlar. Döndürülen belirtecin içinde üç kapsam da bulunur.

Uygulama daha sonra üç kapsamdan herhangi biri için son bir istekte bulunursa (örneğin, scope=tasks.read), Microsoft Entra Id kullanıcının için files.readwritegereken Koşullu Erişim ilkelerini zaten tamamlamış olduğunu görür ve yine içindeki üç iznin tümüne sahip bir belirteç verir.

Haziran 2021

Cihaz kodu akışı UX artık bir uygulama onay istemi içerecek

Geçerlilik tarihi: Haziran 2021.

Etkilenen uç noktalar: v2.0 ve v1.0

Protokol etkilendi: Cihaz kodu akışı

Kimlik avı saldırılarını önlemeye yardımcı olmak için cihaz kodu akışı artık kullanıcının beklediği uygulamada oturum açtığını doğrulayan bir istem içeriyor.

Görüntülenen istem şu şekilde görünür:

Mayıs 2020

Hata düzeltmesi: Microsoft Entra Id artık durum parametresini iki kez URL ile kodlamayacak

Geçerlilik tarihi: Mayıs 2021

Etkilenen uç noktalar: v1.0 ve v2.0

Protokol etkilendi: Uç noktayı ziyaret /authorize eden tüm akışlar (örtük akış ve yetkilendirme kodu akışı)

Microsoft Entra yetkilendirme yanıtında bir hata bulundu ve düzeltildi. Kimlik doğrulamasının /authorize ayağı sırasında, state uygulama durumunu korumak ve CSRF saldırılarını önlemeye yardımcı olmak için istekten gelen parametre yanıta eklenir. Microsoft Entra Id, parametreyi state yanıta eklemeden önce URL ile yanlış kodlanmış ve burada bir kez daha kodlanmıştır. Bu, uygulamaların Microsoft Entra Id yanıtını yanlış reddetmesine neden olur.

Microsoft Entra Id artık bu parametreyi çift kodlamaz ve uygulamaların sonucu doğru şekilde ayrıştırmasına olanak sağlar. Bu değişiklik tüm uygulamalar için yapılacaktır.

Azure Kamu uç noktaları değişiyor

Geçerlilik tarihi: 5 Mayıs 2020 (Bitiş Haziran 2020)

Etkilenen uç noktalar: Tümü

Protokol etkilendi: Tüm akışlar

1 Haziran 2018 tarihinde, Azure Kamu için resmi Microsoft Entra Authority olarak https://login-us.microsoftonline.comhttps://login.microsoftonline.usdeğiştirildi. Bu değişiklik, Microsoft Entra ID'yi de Azure Kamu Microsoft 365 GCC High ve DoD için de geçerlidir. ABD Kamu kiracısında bir uygulamanız varsa, uç noktada kullanıcıların .us oturum açması için uygulamanızı güncelleştirmeniz gerekir.

Microsoft Entra ID, 5 Mayıs 2020'de uç nokta değişikliğini zorunlu kılmaya başlar ve kamu kullanıcılarının genel uç noktayı (microsoftonline.com ) kullanarak ABD Kamu kiracılarında barındırılan uygulamalarda oturum açmasını engeller. Etkilenen uygulamalar hata AADSTS900439 - USGClientNotSupportedOnPublicEndpointgörmeye başlar. Bu hata, uygulamanın genel bulut uç noktasında bir ABD Kamu kullanıcısında oturum açmayı denediğini gösterir. Uygulamanız genel bulut kiracısındaysa ve ABD Kamu kullanıcılarını desteklemeyi amaçlıysa, uygulamanızı açıkça destekleyecek şekilde güncelleştirmeniz gerekir. Bunun için ABD Kamu bulutunda yeni bir uygulama kaydı oluşturulması gerekebilir.

Bu değişikliğin uygulanması, ABD Kamu bulutundan kullanıcıların uygulamada ne sıklıkta oturum açtıklarına bağlı olarak aşamalı bir dağıtım kullanılarak yapılır. ABD Kamu kullanıcılarında nadiren oturum açmış olan uygulamalar önce zorlamayı görür ve ABD Kamu kullanıcıları tarafından sık kullanılan uygulamalar en son uygulanan uygulamalar olur. Tüm uygulamalarda uygulamanın Haziran 2020'de tamamlanmasını bekliyoruz.

Diğer ayrıntılar için lütfen bu geçişle ilgili Azure Kamu blog gönderisine bakın.

Mart 2020

Kullanıcı parolaları 256 karakterle sınırlandırılır.

Geçerlilik tarihi: 13 Mart 2020

Etkilenen uç noktalar: Tümü

Protokol etkilendi: Tüm kullanıcı akışları.

256 karakterden uzun parolaları olan ve doğrudan Microsoft Entra Id'de oturum açan kullanıcılardan (AD FS gibi federasyon IDP'si değil) oturum açabilmek için parolalarını değiştirmeleri istenir. Yöneticiler, kullanıcının parolasını sıfırlamaya yardımcı olmak için istekler alabilir.

Oturum açma günlüklerindeki hata AADSTS 50052: InvalidPasswordExceedsMaxLength ile benzer olacaktır.

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

Düzeltme:

Kullanıcı, parolası izin verilen uzunluk üst sınırını aştığından oturum açamıyor. Parolayı sıfırlamak için yöneticilerine başvurmaları gerekir. Kiracısı için SSPR etkinleştirildiyse, "Parolanızı unuttunuz" bağlantısını izleyerek parolalarını sıfırlayabilir.

Şubat 2020

Oturum açma uç noktasından her HTTP yeniden yönlendirmesine boş parçalar eklenir.

Geçerlilik tarihi: 8 Şubat 2020

Etkilenen uç noktalar: Hem v1.0 hem de v2.0

Protokol etkilendi: Kullanan response_type=query OAuth ve OIDC akışları- bu, bazı durumlarda yetkilendirme kodu akışını ve örtük akışı kapsar.

login.microsoftonline.com'dan HTTP yeniden yönlendirmesi yoluyla bir uygulamaya kimlik doğrulama yanıtı gönderildiğinde, hizmet yanıt URL'sine boş bir parça ekler. Bu, tarayıcının kimlik doğrulama isteğindeki mevcut parçaları temizlemesini sağlayarak bir yeniden yönlendirme saldırıları sınıfını önler. Hiçbir uygulamanın bu davranışa bağımlılığı olmamalıdır.

Ağustos 2019

POST form semantiği daha katı bir şekilde uygulanır - boşluklar ve tırnak işaretleri yoksayılır

Geçerlilik tarihi: 2 Eylül 2019

Etkilenen uç noktalar: Hem v1.0 hem de v2.0

Protokol etkilendi: Post her yerde kullanılır (istemci kimlik bilgileri, yetkilendirme kodu kullanımı, ROPC, OBO ve yenileme belirteci kullanımı)

2 Eylül 2019 haftasının başından itibaren POST yöntemini kullanan kimlik doğrulama istekleri daha katı HTTP standartları kullanılarak doğrulanacaktır. Özellikle, boşluklar ve çift tırnaklar (") artık istek formu değerlerinden kaldırılmaz. Bu değişikliklerin mevcut istemcileri bozması beklenmez ve Microsoft Entra Id'ye gönderilen isteklerin her seferinde güvenilir bir şekilde işlenmesini sağlar. İleride (yukarıya bakın) yinelenen parametreleri ek olarak reddetmeyi ve istekler içinde BOM'u yoksaymayı planlıyoruz.

Örnek:

Bugün, ?e= "f"&g=h ile aynı şekilde ?e=f&g=h ayrıştırılır. Bu nedenlee == f. Bu değişiklikle, artık ayrıştırılacak, böylece e == "f" bu geçerli bir bağımsız değişken olmayacak ve istek artık başarısız olacaktır.

Temmuz 2019

Tek kiracılı uygulamalar için yalnızca uygulama belirteçleri, yalnızca istemci uygulaması kaynak kiracısında mevcutsa verilir

Geçerlilik tarihi: 26 Temmuz 2019

Etkilenen uç noktalar: Hem v1.0 hem de v2.0

Protokol etkilendi: İstemci Kimlik Bilgileri (yalnızca uygulama belirteçleri)

Bir güvenlik değişikliği, 26 Temmuz 2019'da yalnızca uygulama belirteçlerinin (istemci kimlik bilgileri verme yoluyla) verilme şeklini değiştirerek yürürlüğe girecektir. Daha önce, kiracıda veya bu uygulama için onaylanan rollerde bulunmadan bağımsız olarak uygulamaların başka bir uygulamayı çağırmak için belirteç almasına izin veriliyordu. Bu davranış, kaynakların (bazen web API'leri olarak da adlandırılır) tek kiracılı (varsayılan) olarak ayarlanması için istemci uygulamasının kaynak kiracısı içinde mevcut olması gerektiği şekilde güncelleştirildi. İstemci ile API arasında var olan onay hala gerekli değildir ve bir talebin mevcut olduğundan ve API için beklenen değeri içerdiğinden emin olmak roles için uygulamalar kendi yetkilendirme denetimlerini yapmaya devam etmelidir.

Bu senaryonun hata iletisi şu anda şu şekildedir:

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.

Bu sorunu çözmek için Yönetici Onayı deneyimini kullanarak kiracınızda istemci uygulama hizmet sorumlusunu oluşturun veya el ile oluşturun. Bu gereksinim, kiracının uygulamaya kiracı içinde çalışması için izin verdiğinden emin olur.

Örnek istek

https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&... Bu örnekte kaynak kiracısı (yetkili) contoso.com, kaynak uygulaması Contoso kiracısı için çağrılan gateway.contoso.com/api tek kiracılı bir uygulama ve istemci uygulaması ise şeklindedir 00001111-aaaa-2222-bbbb-3333cccc4444. İstemci uygulamasının Contoso.com içinde bir hizmet sorumlusu varsa, bu istek devam edebilir. Ancak başarısız olursa istek yukarıdaki hatayla başarısız olur.

Ancak Contoso ağ geçidi uygulaması çok kiracılı bir uygulamaysa, istemci uygulamasının Contoso.com içinde hizmet sorumlusuna sahip olmasına bakılmaksızın istek devam eder.

Yeniden yönlendirme URI'leri artık sorgu dizesi parametreleri içerebilir

Geçerlilik tarihi: 22 Temmuz 2019

Etkilenen uç noktalar: Hem v1.0 hem de v2.0

Protokol etkilendi: Tüm akışlar

RFC 6749'a göre, Microsoft Entra uygulamaları artık OAuth 2.0 istekleri için statik sorgu parametreleriyle (örneğinhttps://contoso.com/oauth2?idp=microsoft) yeniden yönlendirme (yanıt) URI'lerini kaydedebilir ve kullanabilir. Dinamik yeniden yönlendirme URI'leri bir güvenlik riskini temsil ettikleri için yine de yasaktır ve bu, kimlik doğrulama isteğinde durum bilgilerini korumak için kullanılamaz. Bunun için parametresini state kullanın.

Statik sorgu parametresi, yeniden yönlendirme URI'sinin diğer bölümleri gibi yeniden yönlendirme URI'leri için dize eşleştirmeye tabidir. URI kodu çözülen redirect_uri eşleşen bir dize kaydedilmediyse istek reddedilir. URI uygulama kaydında bulunursa, statik sorgu parametresi dahil olmak üzere kullanıcıyı yeniden yönlendirmek için dizenin tamamı kullanılır.

Şu anda (Temmuz 2019 sonu), Azure portalındaki uygulama kaydı UX'i sorgu parametrelerini engellemeye devam ediyor. Ancak, sorgu parametreleri eklemek ve bunu uygulamanızda test etmek için uygulama bildirimini el ile düzenleyebilirsiniz.

Mart 2019

Döngü istemcileri kesintiye uğrayacak

Geçerlilik tarihi: 25 Mart 2019

Etkilenen uç noktalar: Hem v1.0 hem de v2.0

Protokol etkilendi: Tüm akışlar

İstemci uygulamaları bazen yanlış davranabilir ve kısa bir süre içinde yüzlerce aynı oturum açma isteğini verir. Bu istekler başarılı olabilir veya olmayabilir, ancak hepsi idp için kötü kullanıcı deneyimine ve daha yüksek iş yüklerine katkıda bulunarak tüm kullanıcıların gecikme süresini artırır ve IDP'nin kullanılabilirliğini azaltır. Bu uygulamalar normal kullanım sınırları dışında çalışır ve doğru davranacak şekilde güncelleştirilmelidir.

Yinelenen istekleri birden çok kez veren istemcilere şu invalid_grant hata gönderilir: AADSTS50196: The server terminated an operation because it encountered a loop while processing a request.

Çoğu istemcinin bu hatayı önlemek için davranışı değiştirmesi gerekmez. Bu hatadan yalnızca yanlış yapılandırılmış istemciler (belirteç önbelleğe alınmayan istemciler veya istem döngüleri gösteren istemciler) etkilenir. İstemciler aşağıdaki faktörlere göre örnek başına yerel olarak (tanımlama bilgisi aracılığıyla) izlenir:

• Varsa kullanıcı ipucu

• İstenen kapsamlar veya kaynak

• Client ID

• Yeniden yönlendirme URI'si

• Yanıt türü ve modu

Kısa bir süre içinde (5 dakika) birden çok istekte bulunan uygulamalar döngüye aldıklarını açıklayan bir invalid_grant hata alır. İstenen belirteçlerin yeterince uzun ömürlü yaşam süreleri (varsayılan olarak en az 10 dakika, varsayılan olarak 60 dakika) olduğundan, bu süre boyunca yinelenen istekler gereksizdir.

Tüm uygulamalar sessizce belirteç istemek yerine etkileşimli bir istem göstererek işlemelidir invalid_grant . Bu hatayı önlemek için istemciler aldıkları belirteçleri doğru bir şekilde önbelleğe aldıklarından emin olmalıdır.

2018 Ekim

Yetkilendirme kodları artık yeniden kullanılamaz

Geçerlilik tarihi: 15 Kasım 2018

Etkilenen uç noktalar: Hem v1.0 hem de v2.0

Protokol etkilendi: Kod akışı

Microsoft Entra ID, 15 Kasım 2018'den itibaren uygulamalar için daha önce kullanılan kimlik doğrulama kodlarını kabul etmeyi durduracaktır. Bu güvenlik değişikliği, Microsoft Entra KimliğiniN OAuth belirtimine uygun olarak getirilmesine yardımcı olur ve hem v1 hem de v2 uç noktalarına uygulanır.

Uygulamanız birden çok kaynağın belirteçlerini almak için yetkilendirme kodlarını yeniden kullanıyorsa, yenileme belirteci almak için kodu kullanmanızı ve ardından bu yenileme belirtecini kullanarak diğer kaynaklar için ek belirteçler edinmenizi öneririz. Yetkilendirme kodları yalnızca bir kez kullanılabilir, ancak yenileme belirteçleri birden çok kaynakta birden çok kez kullanılabilir. OAuth kod akışı sırasında kimlik doğrulama kodunu yeniden kullanmaya çalışan tüm yeni uygulamalar invalid_grant hatası alır.

Belirteçleri yenileme hakkında daha fazla bilgi için bkz . Erişim belirteçlerini yenileme. ADAL veya MSAL kullanıyorsanız, bu sizin için kitaplığı tarafından işlenir- öğesinin ikinci örneğini AcquireTokenByAuthorizationCodeAsync ile AcquireTokenSilentAsyncdeğiştirin.

Mayıs 2018

Kimlik belirteçleri OBO akışı için kullanılamaz

Tarih: 1 Mayıs 2018

Etkilenen uç noktalar: Hem v1.0 hem de v2.0

Etkilenen protokoller: Örtük akış ve akış adına

1 Mayıs 2018'de id_tokens yeni uygulamalar için bir OBO akışında onay olarak kullanılamaz. Erişim belirteçleri, aynı uygulamanın istemci ve orta katmanı arasında bile API'lerin güvenliğini sağlamak için kullanılmalıdır. 1 Mayıs 2018'dan önce kaydedilen uygulamalar çalışmaya devam edecek ve erişim belirteci için id_tokens değiş tokuş edebilecek; ancak bu desen en iyi yöntem olarak kabul edilmez.

Bu değişikliği geçici olarak çözmek için aşağıdakileri yapabilirsiniz:

1. Uygulamanız için bir veya daha fazla kapsam içeren bir web API'si oluşturun. Bu açık giriş noktası daha ayrıntılı denetim ve güvenlik sağlar.
2. Uygulamanızın bildiriminde, Azure portalında veya uygulama kayıt portalında, uygulamanın örtük akış üzerinden erişim belirteçleri vermesine izin verildiğinden emin olun. Bu, anahtar üzerinden oauth2AllowImplicitFlow kontrol edilir.
3. İstemci uygulamanız aracılığıyla response_type=id_tokenbir id_token istediğinde, yukarıda oluşturulan web API'si için de bir erişim belirteci (response_type=token) isteyin. Bu nedenle, v2.0 uç noktasını scope kullanırken parametresine api://GUID/SCOPEbenzer görünmelidir. v1.0 uç noktasında parametresi web resource API'sinin uygulama URI'si olmalıdır.
4. Bu erişim belirtecini id_token yerine orta katmana geçirin.