Zarys 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 Platformie tożsamości Microsoft.
Co to jest adres URI przekierowania?
Identyfikator URI przekierowania lub adres URL odpowiedzi to lokalizacja, do której serwer uwierzytelniania Microsoft Entra wysyła użytkownika po pomyślnej autoryzacji i otrzymaniu tokenu 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.
Na przykład w produkcyjnej aplikacji internetowej identyfikator URI przekierowania jest często publicznym punktem końcowym, w którym działa aplikacja, na przykład https://contoso.com/auth-response. Podczas programowania często dodaje się również punkt końcowy, w którym uruchamiasz aplikację lokalnie, na przykład https://127.0.0.1/auth-response lub http://localhost/auth-response. Upewnij się, że wszystkie niepotrzebne środowiska programistyczne/identyfikatory URI przekierowania nie są widoczne w aplikacji produkcyjnej. Można to zrobić, stosując oddzielne rejestracje aplikacji na potrzeby programowania i produkcji.
Dlaczego 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 URI, który nie został dodany w 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 dodawać URI przekierowania do rejestracji aplikacji?
To, 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
- Implicitny przepływ autoryzacji OAuth 2.0
- OpenID Connect
- Protokół SAML logowania jednokrotnego
Nie musisz dodawać do rejestracji aplikacji identyfikatorów URI przekierowania, 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 uwierzytelniania OAuth 2.0 za pomocą hasła właściciela zasobu
- Zintegrowany proces uwierzytelniania Windows
- Dostawca tożsamości SAML 2.0 do jednokrotnego logowania
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 adresu URI do przekierowania aplikacji internetowej
| Typ aplikacji | Typowe języki/ramy | Platforma dla dodawania adresu 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 mobilnych i na komputery stacjonarne
| Typ aplikacji | Typowe języki/frameworki | Platforma do dodawania adresu URI do 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 electron, Windows desktop, UWP, React Native, Xamarin, Android, iOS/macOS | Aplikacje mobilne i desktopowe |
Jeśli tworzysz aplikację dla systemu iOS przy użyciu jednej z poniższych metod, użyj platformy aplikacji mobilnych i komputerowych, 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, których nie wspieramy (Flutter)
- Aplikacje iOS implementujące nasze protokoły OAuth bezpośrednio
- Aplikacje dla systemu macOS korzystające z technologii międzyplatformowych, których nie obsługujemy (Electron)
Aplikacje, które nie wymagają 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 | Przepływ kodu urządzenia więcej informacji |
| Aplikacje, które obsługują hasła wprowadzane bezpośrednio przez użytkowników, zamiast przekierowywać ich na stronę logowania hostowaną przez Entra, pozwalając Entra na bezpieczne zarządzanie hasłem użytkownika. | 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 uwierzytelniania za pomocą hasła właściciela zasobu learn more |
| 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 Windows zamiast menedżera kont sieciowych. | Aplikacja klasyczna lub mobilna, która powinna zostać automatycznie zalogowana po zalogowaniu się użytkownika na komputer z systemem Windows przy użyciu poświadczeń Entra. | Więcej informacji o Zintegrowanym przepływie uwierzytelniania w systemie 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:
Adresy URI przekierowań muszą zaczynać się od schematu
https, z wyjątkami dla niektórych adresów URI przekierowań localhost.Identyfikatory URI przekierowania są rozróżniane pod względem wielkości liter i muszą dokładnie odpowiadać wielkości liter w ścieżce URL uruchomionej aplikacji.
Przykłady:
- Jeśli aplikacja zawiera w swojej ścieżce
.../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 w swojej ścieżce
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 z końcowym ukośnikiem w odpowiedzi.
Przykłady:
-
https://contoso.com/abcjest zwracany jakohttps://contoso.com/abc -
https://contoso.com/abc/response-oidcjest zwracany jakohttps://contoso.com/abc/response-oidc
-
Identyfikatory URI przekierowania nie obsługują znaków specjalnych —
! $ ' ( ) , ;Identyfikatory przekierowania URI nie obsługują międzynarodowych nazw domen
Maksymalna liczba identyfikatorów URI przekierowania i długość identyfikatora URI
Maksymalna liczba identyfikatorów URI przekierowania nie może być zwiększona ze względów bezpieczeństwa. Jeśli scenariusz wymaga większej liczby adresów URI przekierowania niż wynosi maksymalny dozwolony limit, rozważ następujące podejście z wykorzystaniem 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 platformie tożsamości Microsoft.
| Konta, które są zalogowane | Maksymalna liczba URI przekierowania | opis |
|---|---|---|
| Konta służbowe lub edukacyjne Microsoft w dowolnej dzierżawie Microsoft Entra dowolnej organizacji | 256 |
signInAudience pole w manifeście aplikacji jest ustawione na azureADMyOrg lub AzureADMultipleOrgs |
| Osobiste konta Microsoft oraz konta służbowe i szkolne | 100 |
signInAudience pole w manifeście aplikacji jest ustawione na AzureADandPersonalMicrosoftAccount |
Dla każdego identyfikatora URI przekierowania, który dodajesz podczas rejestracji aplikacji, można użyć maksymalnie 256 znaków.
Identyfikatory URI przekierowania w aplikacji w porównaniu do obiektów 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 URI przekierowania dla aplikacji, które tylko logują użytkowników przy użyciu kont służbowych lub szkolnych.
Parametry zapytania nie są dozwolone w identyfikatorach URI przekierowania dla rejestracji dowolnej aplikacji skonfigurowanej do logowania użytkowników za pomocą osobistych kont Microsoft, takich jak Outlook.com (Hotmail), Messenger, OneDrive, MSN, Xbox Live lub Microsoft 365.
| Docelowi użytkownicy logowania do rejestracji aplikacji | Obsługuje parametry zapytania w URI przekierowania |
|---|---|
| Konta tylko w tym katalogu organizacyjnym (tylko Contoso — pojedynczy dzierżawca) | 
|
| Konta w dowolnym katalogu organizacyjnym (dowolny katalog Microsoft Entra — wielodostępność) |
|
| 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 przekierowujących URI opartych na 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
Zgodnie z RFC 8252, sekcja 8.3 i sekcja 7.3, "sprzężenie zwrotne" lub "localhost" identyfikatory URI dla przekierowania mają dwa specjalne względy:
-
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 to, że aplikacje natywne często wymagają zakresów portów efemerycznych, składnik portu (na przykład
:5001lub:443) jest pomijany w celu dopasowania przekierowania URI. 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 URI przekierowania, gdzie różni się jedynie port. Serwer logowania wybiera ten identyfikator URI przekierowania arbitralnie i używa zachowania z nim skojarzonego (na przykład, niezależnie od tego, czy jest to przekierowanie typu
web-,native-, czyspa-).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 procesów podczas rozwoju oprogramowania, należy je rozróżnić przy użyciu składnika ścieżki identyfikatora URI. Na przykład
http://localhost/MyWebAppnie pasuje dohttp://localhost/MyNativeApp.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 ogniowych lub zmienionych interfejsów sieciowych, użyj adresu IP pętli zwrotnej 127.0.0.1 w identyfikatorze URI przekierowania zamiast localhost. Na przykład https://127.0.0.1.
Nie można jednak użyć pola tekstowego URI przekierowania w portalu Azure, aby dodać identyfikator URI przekierowania oparty na sprzężeniu zwrotnym, który używa schematu http.
Aby dodać identyfikator URI przekierowania, który używa schematu http z adresem zwrotnym 127.0.0.1, należy aktualnie zmodyfikować atrybut replyUrlsWithType w manifeście aplikacji.
Ograniczenia dotyczące symboli wieloznacznych w URI przekierowania
Identyfikatory URI z symbolami wieloznacznymi, takie jak https://*.contoso.com, mogą wydawać się wygodne, ale należy ich unikać ze względu na skutki dla 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 lub szkolnych. Identyfikatory URI z symbolami wieloznacznymi są dozwolone, jednak w przypadku aplikacji skonfigurowanych do logowania tylko kont służbowych lub szkolnych w dzierżawie Microsoft Entra organizacji.
Aby dodać URI przekierowania z symbolami wieloznacznymi do rejestracji aplikacji, które logują się na konta służbowe lub szkolne, użyj edytora manifestu aplikacji w portalu Azure w ramach Rejestracje aplikacji. 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 "współużytkowany" adres URI przekierowania, aby aplikacja mogła 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 atakami 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 Microsoft Entra usunie kod HTML z parametru stanu, dlatego upewnij się, że nie przekazujesz zawartości HTML w tym parametrze.
- Gdy Microsoft Entra ID wysyła odpowiedź do "udostępnionego" identyfikatora URI przekierowania, 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 weryfikujesz ochronę 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 sprawdzając nazwę domeny w identyfikatorze URI przekierowania względem tokenu.
Następne kroki
Dowiedz się więcej o rejestracji aplikacji w manifeście aplikacji.