Co nowego w przypadku uwierzytelniania?

Firma Microsoft okresowo dodaje i modyfikuje funkcje Platforma tożsamości Microsoft w celu poprawy bezpieczeństwa, użyteczności i zgodności ze standardami.

O ile nie określono inaczej, opisane tutaj zmiany dotyczą tylko aplikacji zarejestrowanych po dacie wejścia w życie.

Zapoznaj się z tym artykułem regularnie, aby dowiedzieć się więcej o:

• Znane problemy i poprawki
• Zmiany protokołu
• Przestarzałe funkcje

Napiwek

Aby otrzymywać powiadomienia o aktualizacjach tej strony, dodaj ten adres URL do czytnika kanałów informacyjnych RSS:
https://learn.microsoft.com/api/search/rss?search=%22Azure+Active+Directory+breaking+changes+reference%22&locale=en-us

Październik 2023

Zaktualizowany monit środowiska użytkownika zdalnego Połączenie

Data wejścia w życie: październik 2023 r.

Wpływ na punkty końcowe: w wersji 2.0 i 1.0

Protokół, na który ma wpływ: Remote Połączenie

Remote Połączenie to przepływ między urządzeniami używany w scenariuszach związanych z brokerem uwierzytelniania firmy Microsoft i usługą Microsoft Intune obejmującym podstawowe tokeny odświeżania. Aby zapobiec atakom polegającym na wyłudzaniu informacji, przepływ Remote Połączenie będzie otrzymywać zaktualizowany język środowiska użytkownika w celu wywołania, że urządzenie zdalne (urządzenie, które zainicjowało przepływ) będzie mogło uzyskać dostęp do wszystkich aplikacji używanych przez organizację po pomyślnym zakończeniu przepływu.

Wyświetlony monit będzie wyglądać mniej więcej tak:

Czerwiec 2023

Pominięcie oświadczeń poczty e-mail z niezweryfikowanym właścicielem domeny

Data wejścia w życie: czerwiec 2023 r.

Wpływ na punkty końcowe: w wersji 2.0 i 1.0

Zmień

W przypadku aplikacji wielodostępnych wiadomości e-mail, które nie zostały zweryfikowane przez właściciela domeny, są domyślnie pomijane, gdy opcjonalne email oświadczenie jest żądane w ładunku tokenu.

Wiadomość e-mail jest uważana za zweryfikowaną przez właściciela domeny, jeśli:

1. Domena należy do dzierżawy, w której znajduje się konto użytkownika, a administrator dzierżawy dokonał weryfikacji domeny.
2. Wiadomość e-mail pochodzi z konta Microsoft (MSA).
3. Adres e-mail pochodzi z konta Google.
4. Wiadomość e-mail została użyta do uwierzytelniania przy użyciu przepływu jednorazowego kodu dostępu (OTP).

Należy również zauważyć, że konta Facebook i SAML/WS-Fed nie mają zweryfikowanych domen.

Maj 2023

Nazwa roli administratora usługi Power BI zostanie zmieniona na Sieć szkieletowa Administracja istrator.

Data wejścia w życie: czerwiec 2023 r.

Punkty końcowe, których to dotyczy:

• Wyświetlanie listy rólDefinitions — Microsoft Graph w wersji 1.0
• List directoryRoles — Microsoft Graph v1.0

Zmień

Nazwa roli Administracja istrator usługi Power BI zostanie zmieniona na Sieć szkieletowa Administracja istrator.

23 maja 2023 r. firma Microsoft zaprezentowała usługę Microsoft Fabric, która udostępnia środowisko integracji danych oparte na usłudze Data Factory, inżynierię danych obsługiwaną przez usługę Synapse, magazyn danych, naukę o danych i analizy danych w czasie rzeczywistym oraz analizy biznesowej (BI) z usługą Power BI — wszystkie hostowane w rozwiązaniu SaaS skoncentrowanym na środowisku typu lake. Administracja dzierżawą i pojemnością dla tych środowisk jest scentralizowana w portalu Administracja sieci szkieletowej (wcześniej nazywanym portalem administracyjnym usługi Power BI).

Od czerwca 2023 r. rola Administracja istrator usługi Power BI zostanie zmieniona na Sieć szkieletowa Administracja istrator, aby dopasować się do zmieniającego się zakresu i odpowiedzialności tej roli. Wszystkie aplikacje, w tym Microsoft Entra ID, Microsoft Graph API, Microsoft 365 i GDAP, zaczną odzwierciedlać nową nazwę roli w ciągu kilku tygodni.

Przypominamy, że kod aplikacji i skrypty nie powinny podejmować decyzji na podstawie nazwy roli ani nazwy wyświetlanej.

Grudzień 2021

Użytkownicy usług AD FS będą widzieć więcej monitów logowania, aby upewnić się, że prawidłowy użytkownik jest zalogowany.

Data wejścia w życie: grudzień 2021 r.

Punkty końcowe, których dotyczy problem: zintegrowane uwierzytelnianie systemu Windows

Protokół, na który ma wpływ: zintegrowane uwierzytelnianie systemu Windows

Zmień

Obecnie, gdy użytkownik jest wysyłany do usług AD FS w celu uwierzytelnienia, będzie dyskretnie zalogowany do dowolnego konta, które ma już sesję z usługami AD FS. Logowanie dyskretne występuje nawet wtedy, gdy użytkownik zamierzał zalogować się do innego konta użytkownika. Aby zmniejszyć częstotliwość występowania tego nieprawidłowego logowania, począwszy od grudnia identyfikator Entra firmy Microsoft wyśle prompt=login parametr do usług AD FS, jeśli Menedżer kont sieci Web w systemie Windows udostępnia identyfikator login_hint Microsoft Entra podczas logowania, co wskazuje, że określony użytkownik jest wymagany do logowania.

Po spełnieniu powyższych wymagań (WAM jest używany do wysyłania użytkownika do firmy Microsoft Entra ID w celu zalogowania się, element login_hint jest dołączany, a wystąpienie usług AD FS dla domeny użytkownika obsługuje prompt=login) użytkownik nie będzie zalogowany w trybie dyskretnym, a zamiast tego poprosił o podanie nazwy użytkownika w celu kontynuowania logowania się do usług AD FS. Jeśli chcą zalogować się do istniejącej sesji usług AD FS, mogą wybrać opcję "Kontynuuj jako bieżący użytkownik" wyświetlaną poniżej monitu logowania. W przeciwnym razie mogą kontynuować logowanie się przy użyciu nazwy użytkownika.

Ta zmiana zostanie wdrożona w grudniu 2021 r. w ciągu kilku tygodni. Nie zmienia to zachowania logowania dla:

• Aplikacje korzystające bezpośrednio z IWA
• Aplikacje korzystające z protokołu OAuth
• Domeny, które nie są federacyjne z wystąpieniem usług AD FS

Październik 2021

Błąd 50105 został naprawiony, aby nie zwracać interaction_required podczas uwierzytelniania interakcyjnego

Data wejścia w życie: październik 2021 r.

Wpływ na punkty końcowe: w wersji 2.0 i 1.0

Wpływ na protokół: wszystkie przepływy użytkowników dla aplikacji wymagających przypisania użytkownika

Zmień

Błąd 50105 (bieżące oznaczenie) jest emitowany, gdy nieprzypisany użytkownik próbuje zalogować się do aplikacji oznaczonej jako wymagające przypisania użytkownika. Jest to typowy wzorzec kontroli dostępu, a użytkownicy często muszą znaleźć administratora, aby zażądać przypisania w celu odblokowania dostępu. Błąd miał usterkę, która spowodowałaby nieskończone pętle w dobrze zakodowanych aplikacjach, które poprawnie obsłużyły interaction_required odpowiedź o błędzie. interaction_required informuje aplikację o wykonaniu uwierzytelniania interakcyjnego, ale nawet po wykonaniu tej czynności identyfikator Entra firmy Microsoft nadal zwraca interaction_required odpowiedź o błędzie.

Scenariusz błędu został zaktualizowany, tak aby podczas uwierzytelniania nieinterakcyjnego (gdzie prompt=none jest używane do ukrywania środowiska użytkownika), aplikacja zostanie poinstruowana o wykonaniu uwierzytelniania interakcyjnego interaction_required przy użyciu odpowiedzi na błąd. W kolejnym interakcyjnym uwierzytelnieniu identyfikator Entra firmy Microsoft będzie teraz przechowywać użytkownika i wyświetlać komunikat o błędzie bezpośrednio, uniemożliwiając wystąpienie pętli.

Przypominamy, że kod aplikacji nie powinien podejmować decyzji na podstawie ciągów kodu błędu, takich jak AADSTS50105. Zamiast tego postępuj zgodnie z naszymi wskazówkami dotyczącymi obsługi błędów i użyj ustandaryzowanych odpowiedzi uwierzytelniania, takich jak interaction_required i login_required znalezionych w polu standardowym error w odpowiedzi. Inne pola odpowiedzi są przeznaczone tylko do użycia przez ludzi, którzy rozwiązywają problemy.

Możesz przejrzeć bieżący tekst błędu 50105 i więcej informacji na temat usługi wyszukiwania błędów: https://login.microsoftonline.com/error?code=50105.

Identyfikator URI AppId w aplikacjach z jedną dzierżawą będzie wymagał użycia schematu domyślnego lub zweryfikowanych domen

Data wejścia w życie: październik 2021 r.

Wpływ na punkty końcowe: w wersji 2.0 i 1.0

Protokół, na który ma wpływ: wszystkie przepływy

Zmień

W przypadku aplikacji z jedną dzierżawą dodanie lub zaktualizowanie identyfikatora URI identyfikatora AppId sprawdza, czy domena w identyfikatorze URI schematu HTTPS znajduje się na liście zweryfikowanych domen w dzierżawie klienta lub że wartość używa schematu domyślnego (api://{appId}) dostarczonego przez identyfikator Entra firmy Microsoft. Może to uniemożliwić aplikacjom dodawanie identyfikatora URI AppId, jeśli domena nie znajduje się na liście zweryfikowanych domen lub wartość nie używa schematu domyślnego. Aby uzyskać więcej informacji na temat zweryfikowanych domen, zapoznaj się z dokumentacją domen niestandardowych.

Ta zmiana nie wpływa na istniejące aplikacje używające niezweryfikowanych domen w swoich identyfikatorach URI AppId. Weryfikuje tylko nowe aplikacje lub gdy istniejąca aplikacja aktualizuje identyfikator URI identyfikatora lub dodaje nowy do kolekcji identifierUri. Nowe ograniczenia dotyczą tylko identyfikatorów URI dodanych do kolekcji identifierUris aplikacji po 15 października 2021 r. Identyfikatory URI appId już w kolekcji identifierUris aplikacji, gdy ograniczenie zacznie obowiązywać 15 października 2021 r., będzie nadal działać, nawet jeśli dodasz nowe identyfikatory URI do tej kolekcji.

Jeśli żądanie zakończy się niepowodzeniem sprawdzania poprawności, interfejs API aplikacji do tworzenia/aktualizacji zwróci 400 badrequest element do klienta wskazujący wartość HostNameNotOnVerifiedDomain.

Obsługiwane są następujące formaty identyfikatorów URI identyfikatora aplikacji opartego na schematach HTTP i interfejsu API. Zastąp wartości symboli zastępczych zgodnie z opisem na liście poniżej tabeli.

Identyfikator obsługiwanej aplikacji Formaty identyfikatora URI	Przykładowe identyfikatory URI identyfikatorów aplikacji
<api:// appId>	api://fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed
<api:// tenantId>/<appId>	api://a8573488-ff46-450a-b09a-6eca0c6a02dc/fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed
<api:// tenantId>/<ciąg>	api://a8573488-ff46-450a-b09a-6eca0c6a02dc/api
<api:// string>/<appId>	api://productapi/fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed
<https:// tenantInitialDomain.onmicrosoft.com/>< string>	https://contoso.onmicrosoft.com/productsapi
<https:// zweryfikowaneCustomDomain>/<ciąg>	https://contoso.com/productsapi
<https:// ciąg.><verifiedCustomDomain>	https://product.contoso.com
<https:// ciąg.><verifiedCustomDomain>/<string>	https://product.contoso.com/productsapi

• <appId> — właściwość identyfikatora aplikacji (appId) obiektu aplikacji.
• <string> — wartość ciągu dla hosta lub segmentu ścieżki interfejsu API.
• <tenantId> — identyfikator GUID wygenerowany przez platformę Azure do reprezentowania dzierżawy na platformie Azure.
• <tenantInitialDomain> - <tenantInitialDomain.onmicrosoft.com>, gdzie< tenantInitialDomain> jest początkową nazwą domeny twórcą dzierżawy określonym podczas tworzenia dzierżawy.
• <verifiedCustomDomain> — zweryfikowana domena niestandardowa skonfigurowana dla dzierżawy firmy Microsoft Entra.

Uwaga

Jeśli używasz schematu api:// , należy dodać wartość ciągu bezpośrednio po "api://". Na przykład api://< ciąg.> Ta wartość ciągu może być identyfikatorem GUID lub dowolnym ciągiem. Jeśli dodasz wartość identyfikatora GUID, musi być zgodna z identyfikatorem aplikacji lub identyfikatorem dzierżawy. Wartość identyfikatora URI identyfikatora aplikacji musi być unikatowa dla dzierżawy. Jeśli dodasz identyfikator api://< tenantId> jako identyfikator URI identyfikatora aplikacji, nikt inny nie będzie mógł użyć tego identyfikatora URI w dowolnej innej aplikacji. Zaleceniem jest użycie api://< appId>, zamiast tego lub schematu HTTP.

Ważne

Wartość identyfikatora URI identyfikatora aplikacji nie może kończyć się ukośnikiem "/".

Uwaga

Chociaż można bezpiecznie usunąć identyfikatory IdentifierUri dla rejestracji aplikacji w bieżącej dzierżawie, usunięcie identyfikatorówUri może spowodować niepowodzenie klientów w przypadku innych rejestracji aplikacji.

Sierpień 2021

Dostęp warunkowy będzie wyzwalany tylko dla jawnie żądanych zakresów

Data wejścia w życie: sierpień 2021 r., z stopniowym wdrożeniem począwszy od kwietnia.

Wpływ na punkty końcowe: wersja 2.0

Wpływ na protokół: wszystkie przepływy korzystające z dynamicznej zgody

Obecnie aplikacje korzystające z zgody dynamicznej otrzymują wszystkie uprawnienia, dla których mają zgodę, nawet jeśli nie zostały żądane przez nazwę w parametrze scope . Aplikacja żądającą tylko, user.read ale z zgodą files.read , może być zmuszona do przekazania wymagania dostępu warunkowego przypisanego dla programu files.read, na przykład.

Aby zmniejszyć liczbę niepotrzebnych monitów o dostęp warunkowy, identyfikator Entra firmy Microsoft zmienia sposób, w jaki zakresy są udostępniane aplikacjom, więc tylko jawnie żądane zakresy wyzwalają dostęp warunkowy. Aplikacje uzależnione od poprzedniego zachowania identyfikatora Entra firmy Microsoft obejmującego wszystkie zakresy w tokenie — bez względu na to, czy jest to wymagane, czy nie — może zostać przerwane z powodu brakujących zakresów.

Aplikacje otrzymają teraz tokeny dostępu z kombinacją uprawnień: żądane tokeny i te, które mają zgodę, które nie wymagają monitów o dostęp warunkowy. Zakres dostępu dla tokenu jest odzwierciedlany w parametrze odpowiedzi tokenu scope .

Ta zmiana zostanie wprowadzona dla wszystkich aplikacji, z wyjątkiem tych, które mają obserwowaną zależność od tego zachowania. Deweloperzy będą otrzymywać powiadomienia, jeśli zostaną wykluczone z tej zmiany, ponieważ mogą mieć zależność od dodatkowych monitów dostępu warunkowego.

Przykłady

Aplikacja ma zgodę na user.readwartości , files.readwritei tasks.read. files.readwrite ma zastosowane zasady dostępu warunkowego, a pozostałe dwa nie. Jeśli aplikacja wysyła żądanie tokenu dla scope=user.readelementu , a aktualnie zalogowany użytkownik nie przekazał żadnych zasad dostępu warunkowego, wynikowy token będzie przeznaczony dla user.read uprawnień i tasks.read . tasks.read jest uwzględniana, ponieważ aplikacja ma dla niej zgodę i nie wymaga wymuszania zasad dostępu warunkowego.

Jeśli następnie aplikacja zażąda scope=files.readwritedostępu warunkowego wymaganego przez dzierżawę, wymusi wyświetlenie interakcyjnego monitu o uwierzytelnienie, w którym można spełnić zasady dostępu warunkowego. Zwrócony token będzie miał wszystkie trzy zakresy.

Jeśli aplikacja wyśle jedno ostatnie żądanie dla dowolnego z trzech zakresów (np scope=tasks.read. ), identyfikator Microsoft Entra id zobaczy, że użytkownik ukończył już zasady dostępu warunkowego wymagane dla files.readwriteprogramu , a następnie ponownie wyda token ze wszystkimi trzema uprawnieniami w niej.

Czerwiec 2021

Środowisko użytkownika przepływu kodu urządzenia będzie teraz zawierać monit o potwierdzenie aplikacji

Data wejścia w życie: czerwiec 2021 r.

Wpływ na punkty końcowe: w wersji 2.0 i 1.0

Wpływ na protokół: przepływ kodu urządzenia

Aby zapobiec atakom polegającym na wyłudzaniu informacji, przepływ kodu urządzenia zawiera teraz monit, który weryfikuje, czy użytkownik loguje się do oczekiwanej aplikacji.

Wyświetlony monit wygląda następująco:

Maj 2020

Poprawka usterek: Identyfikator entra firmy Microsoft nie będzie już kodować adresu URL parametru stanu dwa razy

Data wejścia w życie: maj 2021 r.

Wpływ na punkty końcowe: w wersji 1.0 i 2.0

Wpływ na protokół: wszystkie przepływy, które odwiedzają /authorize punkt końcowy (przepływ niejawny i przepływ kodu autoryzacji)

Znaleziono usterkę i usunięto w odpowiedzi autoryzacji entra firmy Microsoft. /authorize Podczas uwierzytelniania state parametr żądania jest uwzględniony w odpowiedzi, aby zachować stan aplikacji i pomóc w zapobieganiu atakom CSRF. Microsoft Entra ID niepoprawnie zakodowany state w adresie URL parametr przed wstawieniem go do odpowiedzi, gdzie został zakodowany jeszcze raz. Spowoduje to niepoprawne odrzucenie odpowiedzi przez aplikacje z identyfikatora Entra firmy Microsoft.

Identyfikator entra firmy Microsoft nie będzie już kodować dwukrotnie tego parametru, umożliwiając aplikacjom poprawne analizowanie wyniku. Ta zmiana zostanie wprowadzona dla wszystkich aplikacji.

Zmieniają się punkty końcowe platformy Azure Government

Data wejścia w życie: 5 maja 2020 r. (zakończenie czerwca 2020 r.)

Dotyczy to punktów końcowych: wszystkie

Protokół, na który ma wpływ: wszystkie przepływy

1 czerwca 2018 r. oficjalny urząd Firmy Microsoft Entra dla platformy Azure Government zmienił się z https://login-us.microsoftonline.com na https://login.microsoftonline.us. Ta zmiana została również zastosowana do platformy Microsoft 365 GCC High i DoD, która również jest usługą Microsoft Entra ID platformy Azure Dla instytucji rządowych. Jeśli jesteś właścicielem aplikacji w dzierżawie instytucji rządowych USA, musisz zaktualizować aplikację, aby zalogować użytkowników w punkcie .us końcowym.

5 maja 2020 r. identyfikator Firmy Microsoft Entra rozpocznie wymuszanie zmiany punktu końcowego, co uniemożliwia użytkownikom rządu logowanie się do aplikacji hostowanych w dzierżawach instytucji rządowych USA przy użyciu publicznego punktu końcowego (microsoftonline.com). Aplikacje, których to dotyczy, zaczną pojawiać się błąd AADSTS900439 - USGClientNotSupportedOnPublicEndpoint. Ten błąd wskazuje, że aplikacja próbuje zalogować użytkownika us government w punkcie końcowym chmury publicznej. Jeśli Twoja aplikacja znajduje się w dzierżawie chmury publicznej i ma obsługiwać użytkowników instytucji rządowych USA, musisz zaktualizować aplikację, aby jawnie je obsługiwać. Może to wymagać utworzenia nowej rejestracji aplikacji w chmurze dla instytucji rządowych USA.

Wymuszanie tej zmiany zostanie przeprowadzone przy użyciu stopniowego wprowadzania na podstawie tego, jak często użytkownicy z chmury dla instytucji rządowych USA logują się do aplikacji — aplikacje logowane do użytkowników instytucji rządowych USA często będą widzieć wymuszanie, a aplikacje często używane przez użytkowników instytucji rządowych USA będą miały zastosowanie wymuszania. Oczekujemy, że wymuszanie zostanie ukończone we wszystkich aplikacjach w czerwcu 2020 r.

Aby uzyskać więcej informacji, zobacz wpis w blogu platformy Azure Government dotyczący tej migracji.

Marzec 2020 r.

Hasła użytkowników będą ograniczone do 256 znaków.

Data wejścia w życie: 13 marca 2020 r.

Dotyczy to punktów końcowych: wszystkie

Protokół, na który ma wpływ: wszystkie przepływy użytkowników.

Użytkownicy z hasłami dłuższymi niż 256 znaków, którzy logują się bezpośrednio do identyfikatora Entra firmy Microsoft (nie federacyjnego dostawcy tożsamości, takiego jak usługi AD FS), będą proszeni o zmianę haseł przed zalogowaniem się. Administracja mogą otrzymywać prośby o pomoc w zresetowaniu hasła użytkownika.

Błąd w dziennikach logowania będzie podobny do AADSTS 50052: InvalidPasswordExceedsMaxLength.

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

Korygowania:

Użytkownik nie może się zalogować, ponieważ jego hasło przekracza dozwoloną maksymalną długość. Powinni skontaktować się z administratorem, aby zresetować hasło. Jeśli samoobsługowe resetowanie hasła jest włączone dla swojej dzierżawy, może zresetować hasło, korzystając z linku "Nie pamiętam hasła".

Luty 2020 r.

Puste fragmenty zostaną dołączone do każdego przekierowania HTTP z punktu końcowego logowania.

Data wejścia w życie: 8 lutego 2020 r.

Wpływ na punkty końcowe: zarówno w wersji 1.0, jak i w wersji 2.0

Wpływ na protokół: przepływy OAuth i OIDC, które używają response_type=query — obejmuje to przepływ kodu autoryzacji w niektórych przypadkach i niejawny przepływ.

Gdy odpowiedź uwierzytelniania jest wysyłana z login.microsoftonline.com do aplikacji za pośrednictwem przekierowania HTTP, usługa dołączy pusty fragment do adresu URL odpowiedzi. Zapobiega to klasie ataków przekierowania, zapewniając, że przeglądarka czyści wszelkie istniejące fragmenty żądania uwierzytelniania. Żadne aplikacje nie powinny mieć zależności od tego zachowania.

Sierpień 2019

Semantyka formularzy POST będzie wymuszana bardziej ściśle — spacje i cudzysłowy zostaną zignorowane

Data wejścia w życie: 2 września 2019 r.

Wpływ na punkty końcowe: zarówno w wersji 1.0, jak i w wersji 2.0

Protokół, którego to dotyczy: w dowolnym miejscu jest używana funkcja POST (poświadczenia klienta, realizacja kodu autoryzacji, ROPC, OBO i realizacja tokenu odświeżania)

Począwszy od tygodnia 2 września 2019 r., żądania uwierzytelniania korzystające z metody POST zostaną zweryfikowane przy użyciu bardziej rygorystycznych standardów HTTP. W szczególności spacje i cudzysłowy (") nie zostaną już usunięte z wartości formularza żądania. Te zmiany nie powinny przerywać żadnych istniejących klientów i zapewnią niezawodne obsługę żądań wysyłanych do identyfikatora Entra firmy Microsoft za każdym razem. W przyszłości (patrz powyżej) planujemy dodatkowo odrzucić zduplikowane parametry i zignorować model BOM w ramach żądań.

Przykład:

?e= "f"&g=h Obecnie jest analizowana identycznie jak ?e=f&g=h - więc e == f. Dzięki tej zmianie zostanie ona przeanalizowana tak, aby e == "f" - jest to mało prawdopodobne, aby był to prawidłowy argument, a żądanie teraz zakończy się niepowodzeniem.

Lipiec 2019

Tokeny tylko aplikacji dla aplikacji z jedną dzierżawą są wystawiane tylko wtedy, gdy aplikacja kliencka istnieje w dzierżawie zasobów

Data wejścia w życie: 26 lipca 2019 r.

Wpływ na punkty końcowe: zarówno w wersji 1.0, jak i w wersji 2.0

Protokół, na który ma wpływ: poświadczenia klienta (tokeny tylko dla aplikacji)

Zmiana zabezpieczeń weszła w życie 26 lipca 2019 r. zmieniając sposób wydawania tokenów tylko dla aplikacji (za pośrednictwem udzielania poświadczeń klienta). Wcześniej aplikacje mogły uzyskiwać tokeny do wywoływania dowolnej innej aplikacji, niezależnie od obecności w dzierżawie lub rolach, na które wyraziła zgodę dla tej aplikacji. To zachowanie zostało zaktualizowane tak, aby w przypadku zasobów (czasami nazywanych internetowymi interfejsami API) ustawionych na jedną dzierżawę (wartość domyślna) aplikacja kliencka musi istnieć w dzierżawie zasobów. Istniejąca zgoda między klientem a interfejsem API nadal nie jest wymagana, a aplikacje powinny nadal wykonywać własne kontrole autoryzacji, aby upewnić się, że oświadczenie jest obecne i zawiera oczekiwaną roles wartość interfejsu API.

Komunikat o błędzie dla tego scenariusza obecnie stwierdza:

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.

Aby rozwiązać ten problem, użyj środowiska Administracja Zgoda, aby utworzyć jednostkę usługi aplikacji klienckiej w dzierżawie lub utworzyć ją ręcznie. To wymaganie gwarantuje, że dzierżawa udzieliła aplikacji uprawnienia do działania w ramach dzierżawy.

Przykładowe żądanie

https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&... W tym przykładzie dzierżawa zasobów (urząd) jest contoso.com, aplikacja zasobów jest aplikacją z jedną dzierżawą wywoływaną gateway.contoso.com/api dla dzierżawy Contoso, a aplikacja kliencka to 00001111-aaaa-2222-bbbb-3333cccc4444. Jeśli aplikacja kliencka ma jednostkę usługi w Contoso.com, to żądanie może kontynuować. Jeśli jednak tak nie jest, żądanie zakończy się niepowodzeniem z powyższym błędem.

Jeśli jednak aplikacja bramy firmy Contoso była aplikacją wielodostępną, żądanie będzie kontynuowane niezależnie od aplikacji klienckiej z jednostką usługi w Contoso.com.

Identyfikatory URI przekierowania mogą teraz zawierać parametry ciągu zapytania

Data wejścia w życie: 22 lipca 2019 r.

Wpływ na punkty końcowe: zarówno w wersji 1.0, jak i w wersji 2.0

Protokół, na który ma wpływ: wszystkie przepływy

Na RFC 6749 aplikacje firmy Microsoft Entra mogą teraz rejestrować i używać identyfikatorów URI przekierowania (odpowiedzi) ze statycznymi parametrami zapytania (takimi jak https://contoso.com/oauth2?idp=microsoft) dla żądań OAuth 2.0. Dynamiczne identyfikatory URI przekierowania są nadal zabronione, ponieważ stanowią zagrożenie bezpieczeństwa i nie można ich używać do przechowywania informacji o stanie w żądaniu uwierzytelniania — w tym celu użyj parametru state .

Statyczny parametr zapytania podlega dopasowywaniu ciągów dla identyfikatorów URI przekierowania, takich jak każda inna część identyfikatora URI przekierowania — jeśli żaden ciąg nie jest zarejestrowany, który pasuje do dekodowanego identyfikatora URI redirect_uri, żądanie zostanie odrzucone. Jeśli identyfikator URI zostanie znaleziony w rejestracji aplikacji, cały ciąg zostanie użyty do przekierowania użytkownika, w tym parametru zapytania statycznego.

W tej chwili (koniec lipca 2019 r.) środowisko użytkownika rejestracji aplikacji w witrynie Azure Portal nadal blokuje parametry zapytania. Można jednak ręcznie edytować manifest aplikacji, aby dodać parametry zapytania i przetestować je w aplikacji.

marzec 2019 r.

Sprzężenie klientów zostanie przerwane

Data wejścia w życie: 25 marca 2019 r.

Wpływ na punkty końcowe: zarówno w wersji 1.0, jak i w wersji 2.0

Protokół, na który ma wpływ: wszystkie przepływy

Aplikacje klienckie mogą czasami źle działać, wydając setki tych samych żądań logowania w krótkim czasie. Te żądania mogą lub nie powiodły się, ale wszystkie one przyczyniają się do słabego środowiska użytkownika i zwiększonego obciążenia dostawcy tożsamości, co zwiększa opóźnienie dla wszystkich użytkowników i zmniejsza dostępność dostawcy tożsamości. Te aplikacje działają poza granicami normalnego użycia i powinny być aktualizowane tak, aby działały prawidłowo.

Klienci, którzy wystawiają zduplikowane żądania wielokrotnie, otrzymają invalid_grant komunikat o błędzie: AADSTS50196: The server terminated an operation because it encountered a loop while processing a request.

Większość klientów nie musi zmieniać zachowania, aby uniknąć tego błędu. Ten błąd będzie mieć wpływ tylko na nieprawidłowo skonfigurowanych klientów (bez buforowania tokenu lub tych, którzy już wykazują pętle monitu). Klienci są śledzone lokalnie (za pośrednictwem pliku cookie) na podstawie następujących czynników:

• Wskazówka dla użytkownika, jeśli istnieje

• Żądane zakresy lub zasób

• Client ID

• Adres URI przekierowania

• Typ i tryb odpowiedzi

Aplikacje wysyłające wiele żądań (15+) w krótkim czasie (5 minut) otrzymają invalid_grant błąd wyjaśniający, że są one w pętli. Żądane tokeny mają wystarczająco długie okresy istnienia (domyślnie co najmniej 10 minut, 60 minut), więc powtarzające się żądania w tym okresie są niepotrzebne.

Wszystkie aplikacje powinny obsługiwać invalid_grant , wyświetlając interakcyjny monit, a nie dyskretnie żądając tokenu. Aby uniknąć tego błędu, klienci powinni upewnić się, że poprawnie buforują odbierane tokeny.

2018 października

Kody autoryzacji nie mogą być już ponownie używane

Data wejścia w życie: 15 listopada 2018 r.

Wpływ na punkty końcowe: zarówno w wersji 1.0, jak i w wersji 2.0

Wpływ na protokół: przepływ kodu

Od 15 listopada 2018 r. identyfikator Entra firmy Microsoft przestanie akceptować wcześniej używane kody uwierzytelniania dla aplikacji. Ta zmiana zabezpieczeń ułatwia wprowadzenie identyfikatora Entra firmy Microsoft zgodnie ze specyfikacją protokołu OAuth i będzie wymuszana zarówno w punktach końcowych w wersji 1, jak i w wersji 2.

Jeśli aplikacja ponownie używa kodów autoryzacji w celu pobrania tokenów dla wielu zasobów, zalecamy użycie kodu w celu uzyskania tokenu odświeżania, a następnie użycie tego tokenu odświeżania w celu uzyskania dodatkowych tokenów dla innych zasobów. Kody autoryzacji mogą być używane tylko raz, ale tokeny odświeżania mogą być używane wiele razy w wielu zasobach. Każda nowa aplikacja, która próbuje ponownie użyć kodu uwierzytelniania podczas przepływu kodu OAuth, otrzyma błąd invalid_grant.

Aby uzyskać więcej informacji na temat tokenów odświeżania, zobacz Odświeżanie tokenów dostępu. Jeśli używasz biblioteki ADAL lub MSAL, ta funkcja jest obsługiwana przez bibliotekę — zastąp drugie wystąpienie biblioteki AcquireTokenByAuthorizationCodeAsyncAcquireTokenSilentAsync.

Maj 2018 r.

Tokeny identyfikatorów nie mogą być używane dla przepływu OBO

Data: 1 maja 2018 r.

Wpływ na punkty końcowe: zarówno w wersji 1.0, jak i w wersji 2.0

Wpływ na protokoły: niejawny przepływ i przepływ w imieniu

Po 1 maja 2018 r. nie można użyć id_tokens jako asercji w przepływie OBO dla nowych aplikacji. Tokeny dostępu powinny zamiast tego służyć do zabezpieczania interfejsów API, nawet między klientem a warstwą środkową tej samej aplikacji. Aplikacje zarejestrowane przed 1 maja 2018 r. będą nadal działać i będą mogły wymieniać id_tokens na token dostępu; jednak ten wzorzec nie jest uważany za najlepsze rozwiązanie.

Aby obejść tę zmianę, możesz wykonać następujące czynności:

1. Utwórz internetowy interfejs API dla aplikacji z co najmniej jednym zakresem. Ten jawny punkt wejścia umożliwi bardziej szczegółową kontrolę i zabezpieczenia.
2. W manifeście aplikacji w witrynie Azure Portal lub portalu rejestracji aplikacji upewnij się, że aplikacja może wystawiać tokeny dostępu za pośrednictwem przepływu niejawnego. Jest to kontrolowane za pomocą oauth2AllowImplicitFlow klucza.
3. Gdy aplikacja kliencka żąda id_token za pośrednictwem response_type=id_tokenmetody , zażądaj również tokenu dostępu (response_type=token) dla internetowego interfejsu API utworzonego powyżej. W związku z tym w przypadku korzystania z punktu końcowego scope w wersji 2.0 parametr powinien wyglądać podobnie do api://GUID/SCOPE. W punkcie końcowym resource w wersji 1.0 parametr powinien być identyfikatorem URI aplikacji internetowego interfejsu API.
4. Przekaż ten token dostępu do warstwy środkowej zamiast id_token.