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-oidcw identyfikatorze URI przekierowania. Ponieważ przeglądarka internetowa traktuje ścieżki jako wrażliwe na wielkość liter, pliki cookie skojarzone z usługą.../abc/response-oidcmogą zostać wykluczone w przypadku przekierowania do niezgodnego.../ABC/response-oidcadresu URL.
- Jeśli aplikacja zawiera element ścieżki
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 toquerylubfragment.Przykłady:
https://contoso.comjest zwracany jakohttps://contoso.com/http://localhost:7071jest zwracany jakohttp://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/abcjest zwracany jakohttps://contoso.com/abchttps://contoso.com/abc/response-oidcjest zwracany jakohttps://contoso.com/abc/response-oidc
Identyfikatory URI przekierowania nie obsługują znaków specjalnych —
! $ ' ( ) , ;Identyfikatory URI przekierowania nie obsługują nazw domen międzynarodowych
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:
httpSchematy 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/myApphttps://localhost/myApp
- Ze względu na zakresy portów efemerycznych często wymagane przez aplikacje natywne, składnik portu (na przykład
:5001lub:443) jest ignorowany na potrzeby dopasowywania identyfikatora URI przekierowania. W rezultacie wszystkie te identyfikatory URI są uznawane za równoważne:http://localhost/MyApphttp://localhost:1234/MyApphttp://localhost:5000/MyApphttp://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-, czyspa-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/MyWebAppwartość nie jest zgodnahttp://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:
- Utwórz identyfikator URI przekierowania "współużytkowany" dla aplikacji, aby przetworzyć tokeny zabezpieczające otrzymane z punktu końcowego autoryzacji.
- 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.
- 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.
- Gdy identyfikator entra firmy Microsoft wysyła odpowiedź do identyfikatora URI przekierowania "udostępnionego", wysyła parametr stanu z powrotem do aplikacji.
- 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.