Konspekt i ograniczenia dotyczące identyfikatora URI przekierowania (adresu URL odpowiedzi)

Aby zalogować użytkownika, aplikacja musi wysłać żądanie logowania do punktu końcowego autoryzacji Entra firmy Microsoft z identyfikatorem URI przekierowania określonym jako parametr. Identyfikator URI przekierowania jest krytyczną funkcją zabezpieczeń, która gwarantuje, że serwer uwierzytelniania Entra firmy Microsoft wysyła tylko kody autoryzacji i tokeny dostępu do zamierzonego adresata. W tym artykule opisano funkcje i ograniczenia identyfikatorów URI przekierowania w Platforma tożsamości Microsoft.

Co to jest identyfikator URI przekierowania?

Identyfikator URI przekierowania lub adres URL odpowiedzi to lokalizacja, w której serwer uwierzytelniania Firmy Microsoft Entra wysyła użytkownika po pomyślnym autoryzowanym i udzielonym tokenowi dostępu. Aby zalogować użytkownika, aplikacja musi wysłać żądanie logowania z identyfikatorem URI przekierowania określonym jako parametr, więc po pomyślnym zalogowaniu użytkownika serwer uwierzytelniania przekieruje użytkownika i wyda token dostępu do identyfikatora URI przekierowania określonego w żądaniu logowania.

Dlaczego identyfikatory URI przekierowania muszą zostać dodane do rejestracji aplikacji?

Ze względów bezpieczeństwa serwer uwierzytelniania nie będzie przekierowywać użytkowników ani wysyłać tokenów do identyfikatora URI, który nie został dodany do rejestracji aplikacji. Serwery logowania firmy Microsoft Entra przekierowują tylko użytkowników i wysyłają tokeny w celu przekierowania identyfikatorów URI dodanych do rejestracji aplikacji. Jeśli identyfikator URI przekierowania określony w żądaniu logowania nie jest zgodny z żadnymi identyfikatorami URI przekierowania dodanymi w aplikacji, zostanie wyświetlony komunikat o błędzie, taki jak AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application.

Aby uzyskać więcej informacji na temat kodów błędów, zobacz Kody błędów uwierzytelniania i autoryzacji firmy Microsoft.

Czy należy dodać identyfikator URI przekierowania do rejestracji aplikacji?

Czy należy dodać identyfikator URI przekierowania do rejestracji aplikacji, zależy od protokołu autoryzacji używanego przez aplikację. Należy dodać odpowiednie identyfikatory URI przekierowania do rejestracji aplikacji, jeśli aplikacja korzysta z następujących protokołów autoryzacji:

• Przepływ kodu autoryzacji OAuth 2.0
• Przepływ poświadczeń klienta protokołu OAuth 2.0
• Przepływ przyznawania niejawnego protokołu OAuth 2.0
• OpenID Connect
• Protokół SAML logowania jednokrotnego

Nie musisz dodawać identyfikatorów URI przekierowania do rejestracji aplikacji, jeśli aplikacja korzysta z następujących protokołów autoryzacji lub funkcji.

• Uwierzytelnianie natywne
• Przepływ kodu urządzenia OAuth 2.0
• Przepływ OAuth 2.0 On-Behalf-Of
• Przepływ poświadczeń hasła właściciela zasobu OAuth 2.0
• Przepływ zintegrowanego uwierzytelniania systemu Windows
• Dostawca tożsamości SAML 2.0 dla Logowanie jednokrotne

Do której platformy należy dodać identyfikatory URI przekierowania?

Jeśli utworzona aplikacja zawiera jeden lub wiele identyfikatorów URI przekierowania w rejestracji aplikacji, musisz włączyć publiczną konfigurację przepływu klienta. Poniższe tabele zawierają wskazówki dotyczące typu identyfikatora URI przekierowania, którego należy dodać lub nie należy dodawać na podstawie platformy, na której tworzysz aplikację.

Konfiguracja identyfikatora URI przekierowania aplikacji internetowej

Typ aplikacji	Typowe języki/struktury	Platforma do dodawania identyfikatora URI przekierowania w rejestracji aplikacji
Tradycyjna aplikacja internetowa, w której większość logiki aplikacji jest wykonywana na serwerze	Node.js, web, ASP.NET, Python, Java, ASP.NET Core, PHP, Ruby, Blazor Server	Internet
Jednostronicowa aplikacja, w której większość logiki interfejsu użytkownika jest wykonywana w przeglądarce internetowej komunikującej się z serwerem internetowym głównie przy użyciu internetowych interfejsów API	JavaScript, Angular, React, Blazor WebAssembly, Vue.js	Aplikacja jednostronicowa (SPA)

Konfiguracja identyfikatora URI przekierowania aplikacji mobilnej i klasycznej

Typ aplikacji	Typowe języki/struktury	Platforma do dodawania identyfikatora URI przekierowania w rejestracji aplikacji
Aplikacja systemu iOS lub macOS z wyłączeniem scenariuszy wymienionych poniżej tej tabeli	Swift, Objective-C, Xamarin	IOS/macOS
Aplikacja dla systemu Android	Java, Kotlin, Xamarin	Android
Aplikacja uruchamiana natywnie na urządzeniu przenośnym lub komputerze stacjonarnym	Node.js elektron, komputer z systemem Windows, platforma UWP, platforma React Native, Xamarin, Android, iOS/macOS	Aplikacje mobilne i klasyczne

Jeśli tworzysz aplikację dla systemu iOS przy użyciu jednej z następujących metod, użyj platformy aplikacje mobilne i klasyczne, aby dodać identyfikator URI przekierowania:

• Aplikacje systemu iOS korzystające ze starszych zestawów SDK (ADAL)
• Aplikacje dla systemu iOS korzystające z zestawów SDK typu open source (AppAuth)
• Aplikacje dla systemu iOS korzystające z technologii międzyplatformowych nie są obsługiwane (Flutter)
• Aplikacje systemu iOS implementowanie naszych protokołów OAuth bezpośrednio
• Aplikacje dla systemu macOS korzystające z technologii międzyplatformowych, których nie obsługujemy (Electron)

Aplikacje, które nie wymagają identyfikatora URI przekierowania

Typ aplikacji	Przykłady/notatki	Skojarzony przepływ protokołu OAuth
Aplikacje uruchomione na urządzeniach, na których nie ma klawiatury	Aplikacje działające w inteligentnym telewizorze, urządzeniu IoT lub drukarce	Więcej informacji o przepływie kodu urządzenia
Aplikacje obsługujące hasła wprowadzane bezpośrednio przez użytkowników zamiast przekierowywać użytkowników do witryny internetowej entra hosted login i umożliwiają aplikacji Entra obsługę hasła użytkownika w bezpieczny sposób.	Tego przepływu należy używać tylko wtedy, gdy inne bezpieczniejsze przepływy, takie jak przepływ kodu autoryzacji, nie są opłacalne, ponieważ nie są tak bezpieczne.	Więcej informacji o przepływie poświadczeń hasła właściciela zasobu
Aplikacje klasyczne lub mobilne działające w systemie Windows lub na maszynie połączonej z domeną systemu Windows (przyłączone do usługi AD lub Azure AD) przy użyciu zintegrowanego przepływu uwierzytelniania systemu Windows zamiast menedżera kont sieci Web	Aplikacja klasyczna lub mobilna, która powinna zostać automatycznie zalogowana po zalogowaniu się użytkownika do systemu Windows PC przy użyciu poświadczeń entra	Więcej informacji o zintegrowanym przepływie uwierzytelniania systemu Windows

Jakie są ograniczenia identyfikatorów URI przekierowania dla aplikacji firmy Microsoft Entra?

Model aplikacji Microsoft Entra określa następujące ograniczenia dotyczące przekierowywania identyfikatorów URI:

• Identyfikatory URI przekierowania muszą zaczynać się od schematu https, z wyjątkami dla niektórych identyfikatorów URI przekierowania hosta lokalnego .

• W identyfikatorach URI przekierowania uwzględniana jest wielkość liter i musi być zgodna ze ścieżką adresu URL uruchomionej aplikacji.

  Przykłady:

  • Jeśli aplikacja zawiera element ścieżki .../abc/response-oidc, nie należy określać .../ABC/response-oidc w identyfikatorze URI przekierowania. Ponieważ przeglądarka internetowa traktuje ścieżki jako wrażliwe na wielkość liter, pliki cookie skojarzone z usługą .../abc/response-oidc mogą zostać wykluczone w przypadku przekierowania do niezgodnego .../ABC/response-oidc adresu URL.

• Identyfikatory URI przekierowania nieskonfigurowane z segmentem ścieżki są zwracane z końcowym ukośnikiem ('/') w odpowiedzi. Ma to zastosowanie tylko wtedy, gdy tryb odpowiedzi to query lub fragment.

  Przykłady:

  • https://contoso.com jest zwracany jako https://contoso.com/
  • http://localhost:7071 jest zwracany jako http://localhost:7071/

• Identyfikatory URI przekierowania zawierające segment ścieżki nie są dołączane do końcowego ukośnika w odpowiedzi.

  Przykłady:

  • https://contoso.com/abc jest zwracany jako https://contoso.com/abc
  • https://contoso.com/abc/response-oidc jest zwracany jako https://contoso.com/abc/response-oidc

• Identyfikatory URI przekierowania nie obsługują znaków specjalnych — ! $ ' ( ) , ;

Maksymalna liczba identyfikatorów URI przekierowania i długości identyfikatora URI

Maksymalna liczba identyfikatorów URI przekierowania nie może być podniesiona ze względów bezpieczeństwa. Jeśli scenariusz wymaga większej liczby identyfikatorów URI przekierowania niż dozwolony maksymalny limit, rozważ następujące podejście parametru stanu jako rozwiązanie. W poniższej tabeli przedstawiono maksymalną liczbę identyfikatorów URI przekierowania, które można dodać do rejestracji aplikacji w Platforma tożsamości Microsoft.

Konta, które są zalogowane	Maksymalna liczba identyfikatorów URI przekierowania	opis
Konta służbowe firmy Microsoft w dowolnej dzierżawie firmy Microsoft	256	signInAudience pole w manifeście aplikacji jest ustawione na azureADMyOrg lub AzureADMultipleOrgs
Osobiste konta Microsoft i konta służbowe	100	signInAudience pole w manifeście aplikacji jest ustawione na AzureADandPersonalMicrosoftAccount

Dla każdego identyfikatora URI przekierowania dodawanego do rejestracji aplikacji można użyć maksymalnie 256 znaków.

Identyfikatory URI przekierowania w aplikacji a obiekty jednostki usługi

• Zawsze należy dodawać identyfikatory URI przekierowania tylko do obiektu aplikacji.
• Nigdy nie należy dodawać wartości identyfikatora URI przekierowania do jednostki usługi, ponieważ te wartości można usunąć, gdy obiekt jednostki usługi synchronizuje się z obiektem aplikacji. Może się to zdarzyć z powodu dowolnej operacji aktualizacji, która wyzwala synchronizację między dwoma obiektami.

Obsługa parametrów zapytania w identyfikatorach URI przekierowania

Parametry zapytania są dozwolone w identyfikatorach URI przekierowania dla aplikacji, które logują użytkowników tylko przy użyciu kont służbowych.

Parametry zapytania nie są dozwolone w identyfikatorach URI przekierowania dla żadnej rejestracji aplikacji skonfigurowanej do logowania użytkowników przy użyciu osobistych kont Microsoft, takich jak Outlook.com (Hotmail), Messenger, OneDrive, MSN, Xbox Live lub Microsoft 365.

Odbiorcy logowania do rejestracji aplikacji	Obsługuje parametry zapytania w identyfikatorze URI przekierowania
Konta tylko w tym katalogu organizacyjnym (tylko Contoso — pojedyncza dzierżawa)
Konta w dowolnym katalogu organizacyjnym (dowolnym katalogu usługi Microsoft Entra — wielodostępnym)
Konta w dowolnym katalogu organizacyjnym (dowolny katalog Microsoft Entra — multitenant) i osobiste konta Microsoft (takie jak Skype i Xbox)
Tylko osobiste konta Microsoft

Obsługiwane schematy

HTTPS: schemat HTTPS (https://) jest obsługiwany dla wszystkich identyfikatorów URI przekierowania opartych na protokole HTTP.

HTTP: Schemat HTTP (http://) jest obsługiwany tylko w przypadku identyfikatorów URI hosta lokalnego i powinien być używany tylko podczas aktywnego tworzenia i testowania aplikacji lokalnych.

Przykładowy identyfikator URI przekierowania	Poprawność
https://contoso.com	Prawidłowe
https://contoso.com/abc/response-oidc	Prawidłowe
https://localhost	Prawidłowe
http://contoso.com/abc/response-oidc	Nieprawidłowy
http://localhost	Prawidłowe
http://localhost/abc	Prawidłowe

Wyjątki hosta lokalnego

Na 8252 sekcje RFC 8.3 i 7.3, "sprzężenie zwrotne" lub "localhost" identyfikatory URI przekierowania są dostępne w dwóch specjalnych zagadnieniach:

1. http Schematy identyfikatorów URI są akceptowalne, ponieważ przekierowanie nigdy nie opuszcza urządzenia. W związku z tym oba te identyfikatory URI są dopuszczalne:
   • http://localhost/myApp
   • https://localhost/myApp
2. Ze względu na zakresy portów efemerycznych często wymagane przez aplikacje natywne, składnik portu (na przykład :5001 lub :443) jest ignorowany na potrzeby dopasowywania identyfikatora URI przekierowania. W rezultacie wszystkie te identyfikatory URI są uznawane za równoważne:
   • http://localhost/MyApp
   • http://localhost:1234/MyApp
   • http://localhost:5000/MyApp
   • http://localhost:8080/MyApp

Z punktu widzenia rozwoju oznacza to kilka rzeczy:

• Nie rejestruj wielu identyfikatorów URI przekierowania, w których różni się tylko port. Serwer logowania wybiera jeden arbitralnie i używa zachowania skojarzonego z tym identyfikatorem webURI przekierowania (na przykład niezależnie od tego, czy jest to przekierowanie -, native-, czy spa-type).

  Jest to szczególnie ważne, gdy chcesz używać różnych przepływów uwierzytelniania w tej samej rejestracji aplikacji, na przykład zarówno przyznawania kodu autoryzacji, jak i niejawnego przepływu. Aby skojarzyć poprawne zachowanie odpowiedzi z każdym identyfikatorem URI przekierowania, serwer logowania musi mieć możliwość rozróżnienia między identyfikatorami URI przekierowania i nie może tego zrobić, gdy tylko port się różni.

• Aby zarejestrować wiele identyfikatorów URI przekierowania na hoście lokalnym w celu przetestowania różnych przepływów podczas programowania, należy je rozróżnić przy użyciu składnika ścieżki identyfikatora URI. Na przykład http://localhost/MyWebApp wartość nie jest zgodna http://localhost/MyNativeAppz parametrem .

• Adres sprzężenia zwrotnego protokołu IPv6 ([::1]) nie jest obecnie obsługiwany.

Preferuj 127.0.0.1 za pośrednictwem hosta lokalnego

Aby zapobiec uszkodzeniu aplikacji z powodu błędnie skonfigurowanych zapór lub zmienionych interfejsów sieciowych, użyj adresu 127.0.0.1 sprzężenia zwrotnego literału IP w identyfikatorze URI przekierowania zamiast localhost. Na przykład https://127.0.0.1.

Nie można jednak użyć pola tekstowego Identyfikatory URI przekierowania w witrynie Azure Portal, aby dodać identyfikator URI przekierowania opartego na sprzężeniu zwrotnym, który używa schematu http :

Aby dodać identyfikator URI przekierowania, który używa schematu http z adresem sprzężenia zwrotnego 127.0.0.1 , należy obecnie zmodyfikować atrybut replyUrlsWithType w manifeście aplikacji.

Ograniczenia dotyczące symboli wieloznacznych w identyfikatorach URI przekierowania

Identyfikatory URI z symbolami wieloznacznymi, takie jak https://*.contoso.com mogą wydawać się wygodne, ale należy unikać z powodu skutków bezpieczeństwa. Zgodnie ze specyfikacją protokołu OAuth 2.0 (sekcja 3.1.2 RFC 6749) identyfikator URI punktu końcowego przekierowania musi być bezwzględnym identyfikatorem URI. W związku z tym, gdy skonfigurowany wieloznaczny identyfikator URI pasuje do identyfikatora URI przekierowania, ciągi zapytania i fragmenty w identyfikatorze URI przekierowania są usuwane.

Identyfikatory URI z symbolami wieloznacznymi są obecnie nieobsługiwane w rejestracjach aplikacji skonfigurowanych do logowania się na osobistych kontach Microsoft i kontach służbowych. Identyfikatory URI z symbolami wieloznacznymi są dozwolone, jednak w przypadku aplikacji skonfigurowanych do logowania tylko kont służbowych w dzierżawie firmy Microsoft w organizacji.

Aby dodać identyfikatory URI przekierowania z symbolami wieloznacznymi do rejestracji aplikacji logujących się na kontach służbowych, użyj edytora manifestu aplikacji w Rejestracje aplikacji w witrynie Azure Portal. Chociaż istnieje możliwość ustawienia identyfikatora URI przekierowania za pomocą symbolu wieloznakowego przy użyciu edytora manifestu, zdecydowanie zalecamy stosowanie się do sekcji 3.1.2 z RFC 6749. i używać tylko bezwzględnych identyfikatorów URI.

Jeśli w twoim scenariuszu jest wymagana większa liczba identyfikatorów URI przekierowania niż dozwolony maksymalny limit, rozważ następujące podejście do parametru stanu zamiast dodawania identyfikatora URI przekierowania z symbolami wieloznacznymi.

Używanie parametru stanu

Jeśli masz kilka domen podrzędnych i twój scenariusz wymaga tego, po pomyślnym uwierzytelnieniu nastąpi przekierowanie użytkowników do tej samej strony, z której zaczęli, użycie parametru stanu może być przydatne.

W tym podejściu:

1. Utwórz identyfikator URI przekierowania "współużytkowany" dla aplikacji, aby przetworzyć tokeny zabezpieczające otrzymane z punktu końcowego autoryzacji.
2. Aplikacja może wysyłać parametry specyficzne dla aplikacji (takie jak adres URL poddomeny, z którego pochodzi użytkownik lub cokolwiek innego, jak informacje o znakowaniu) w parametrze stanu. W przypadku używania parametru stanu należy chronić przed ochroną CSRF zgodnie z sekcją 10.12 RFC 6749.
3. Parametry specyficzne dla aplikacji obejmują wszystkie informacje potrzebne aplikacji do renderowania poprawnego środowiska dla użytkownika, czyli konstruowanie odpowiedniego stanu aplikacji. Punkt końcowy autoryzacji firmy Microsoft usuwa kod HTML z parametru stanu, dlatego upewnij się, że nie przekazujesz zawartości HTML w tym parametrze.
4. Gdy identyfikator entra firmy Microsoft wysyła odpowiedź do identyfikatora URI przekierowania "udostępnionego", wysyła parametr stanu z powrotem do aplikacji.
5. Następnie aplikacja może użyć wartości w parametrze stanu, aby określić, do którego adresu URL należy dalej wysyłać użytkownika. Upewnij się, że sprawdzasz poprawność ochrony CSRF.

Ostrzeżenie

Takie podejście umożliwia klientowi, którego bezpieczeństwo zostało naruszone, modyfikowanie dodatkowych parametrów wysyłanych w parametrze stanu, co powoduje przekierowanie użytkownika do innego adresu URL, czyli otwartego zagrożenia przekierowania opisanego w specyfikacji RFC 6819. W związku z tym klient musi chronić te parametry, szyfrując stan lub weryfikując go w inny sposób, na przykład weryfikując nazwę domeny w identyfikatorze URI przekierowania przed tokenem.

Następne kroki

Dowiedz się więcej o manifeście aplikacji rejestracji aplikacji.