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

  • Artykuł

Identyfikator URI przekierowania, czyli adres URL odpowiedzi, jest to lokalizacja, do której serwer autoryzacji wysyła użytkownika po pomyślnym autoryzowaniu aplikacji i przyznaniu kodu autoryzacji lub tokenu dostępu. Serwer autoryzacji wysyła kod lub token do przekierowanego identyfikatora URI, dlatego ważne jest, aby zarejestrować właściwą lokalizację w ramach procesu rejestracji aplikacji.

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. Istnieją pewne wyjątki dla 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. Jeśli na przykład 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

W tej 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

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.

Maksymalna długość identyfikatora URI

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 dodawaj identyfikatory URI przekierowania tylko do obiektu aplikacji.
  • 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 (np. Skype, 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 wybierze jeden arbitralnie i użyje 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 przez nieprawidłowo skonfigurowane zapory lub zmienione interfejsy sieciowe, 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 :

Error dialog in Azure portal showing disallowed http-based loopback redirect URI

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 będą zawierać 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, wyśle 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.