Eksplorowanie uwierzytelniania i autoryzacji w usłudze App Service

Ukończone

usługa aplikacja systemu Azure zapewnia wbudowaną obsługę uwierzytelniania i autoryzacji. Możesz logować użytkowników i uzyskiwać dostęp do danych, zapisując minimalny lub żaden kod w aplikacji internetowej, interfejs API RESTful, zaplecze mobilne lub usługa Azure Functions.

Dlaczego warto używać wbudowanego uwierzytelniania?

Nie musisz używać usługi App Service do uwierzytelniania i autoryzacji. Wiele struktur internetowych jest powiązanych z funkcjami zabezpieczeń i można ich używać, jeśli chcesz. Jeśli potrzebujesz większej elastyczności niż zapewnia usługa App Service, możesz również napisać własne narzędzia.

Wbudowana funkcja uwierzytelniania dla usług App Service i Azure Functions pozwala zaoszczędzić czas i nakład pracy, zapewniając gotowe do użycia uwierzytelnianie przy użyciu federacyjnych dostawców tożsamości, co pozwala skupić się na pozostałej części aplikacji.

• usługa aplikacja systemu Azure umożliwia integrację różnych funkcji uwierzytelniania z aplikacją internetową lub interfejsem API bez samodzielnego implementowania ich.
• Uwierzytelnianie jest wbudowane bezpośrednio w platformę i nie wymaga żadnego określonego języka, zestawu SDK, wiedzy z zakresu zabezpieczeń ani kodu.
• Można zintegrować z wieloma dostawcami logowania. Na przykład Microsoft Entra ID, Facebook, Google, X.

Dostawcy tożsamości

Usługa App Service używa tożsamości federacyjnej, w której dostawca tożsamości innej firmy zarządza tożsamościami użytkowników i przepływem uwierzytelniania. Domyślnie są dostępni następujący dostawcy tożsamości:

Dostawca	Punkt końcowy logowania	Wskazówki dotyczące instrukcji
Platforma tożsamości firmy Microsoft	/.auth/login/aad	Logowanie Platforma tożsamości Microsoft usługi App Service
Facebook	/.auth/login/facebook	Identyfikator logowania usługi App Service w serwisie Facebook
Google	/.auth/login/google	Identyfikator logowania google usługi App Service
X	/.auth/login/twitter	Logowanie do usługi App Service X
Dowolny dostawca openID Connect	/.auth/login/<providerName>	Logowanie do programu OpenID Connect w usłudze App Service
GitHub	/.auth/login/github	Identyfikator logowania usługi GitHub w usłudze App Service

Po włączeniu uwierzytelniania i autoryzacji z jednym z tych dostawców jego punkt końcowy logowania jest dostępny na potrzeby uwierzytelniania użytkownika i weryfikacji tokenów uwierzytelniania od dostawcy. Możesz udostępnić swoim użytkownikom dowolną liczbę tych opcji logowania.

Jak to działa

Moduł uwierzytelniania i autoryzacji działa w tej samej piaskownicy co kod aplikacji. Po włączeniu każde przychodzące żądanie HTTP przechodzi przez nie przed przekazaniem kodu aplikacji. Ten moduł obsługuje kilka rzeczy dla aplikacji:

• Uwierzytelnia użytkowników i klientów przy użyciu określonego dostawcy tożsamości
• Weryfikuje, przechowuje i odświeża tokeny OAuth wystawione przez skonfigurowanego dostawcę tożsamości
• Zarządza uwierzytelnianą sesją
• Wprowadza informacje o tożsamości do nagłówków żądań HTTP

Moduł działa oddzielnie od kodu aplikacji i można go skonfigurować przy użyciu ustawień usługi Azure Resource Manager lub pliku konfiguracji. Nie są wymagane żadne zestawy SDK, określone języki programowania ani zmiany w kodzie aplikacji.

Uwaga

W systemie Linux i kontenerach moduł uwierzytelniania i autoryzacji działa w osobnym kontenerze izolowanym od kodu aplikacji. Ponieważ nie jest ona uruchamiana w procesie, nie jest możliwa bezpośrednia integracja z określonymi strukturami językowymi.

Przepływ uwierzytelniania

Przepływ uwierzytelniania jest taki sam dla wszystkich dostawców, ale różni się w zależności od tego, czy chcesz zalogować się przy użyciu zestawu SDK dostawcy.

• Bez zestawu SDK dostawcy: aplikacja deleguje federacyjne logowanie do usługi App Service. To delegowanie jest zwykle w przypadku aplikacji przeglądarki, które mogą przedstawić użytkownikowi stronę logowania dostawcy. Kod serwera zarządza procesem logowania i jest określany jako przepływ kierowany przez serwer lub przepływ serwera.

• Zestaw SDK dostawcy: aplikacja loguje użytkowników do dostawcy ręcznie, a następnie przesyła token uwierzytelniania do usługi App Service w celu weryfikacji. Jest to zwykle przypadek aplikacji bez przeglądarki, które nie mogą przedstawić użytkownikowi strony logowania dostawcy. Kod aplikacji zarządza procesem logowania i jest określany jako przepływ kierowany przez klienta lub przepływ klienta. Dotyczy to interfejsów API REST, usługi Azure Functions, klientów przeglądarki JavaScript i natywnych aplikacji mobilnych logujących użytkowników przy użyciu zestawu SDK dostawcy.

W poniższej tabeli przedstawiono kroki przepływu uwierzytelniania.

Krok	Bez zestawu SDK dostawcy	Zestaw SDK dostawcy
Logowanie użytkownika	Przekierowuje klienta do /.auth/login/<provider>.	Kod klienta loguje użytkownika bezpośrednio za pomocą zestawu SDK dostawcy i otrzymuje token uwierzytelniania. Aby uzyskać informacje, zobacz dokumentację dostawcy.
Po uwierzytelnianiu	Dostawca przekierowuje klienta do /.auth/login/<provider>/callback.	Kod klienta publikuje token od dostawcy do /.auth/login/<provider> w celu weryfikacji.
Ustanawianie sesji uwierzytelnionej	Usługa App Service dodaje uwierzytelniony plik cookie do odpowiedzi.	Usługa App Service zwraca własny token uwierzytelniania do kodu klienta.
Obsługa uwierzytelnionej zawartości	Klient zawiera plik cookie uwierzytelniania w kolejnych żądaniach (automatycznie obsługiwane przez przeglądarkę).	Kod klienta przedstawia token uwierzytelniania w X-ZUMO-AUTH nagłówku (automatycznie obsługiwane przez zestawy SDK klienta usługi Mobile Apps).

W przypadku przeglądarek klienckich usługa App Service może automatycznie kierować wszystkich nieuwierzytelnionych użytkowników do usługi /.auth/login/<provider>. Możesz również przedstawić użytkownikom co najmniej jeden /.auth/login/<provider> link, aby zalogować się do aplikacji przy użyciu wybranego dostawcy.

Zachowanie autoryzacji

W witrynie Azure Portal można skonfigurować usługę App Service z wieloma zachowaniami, gdy żądanie przychodzące nie jest uwierzytelnione.

• Zezwalaj na nieuwierzytelnione żądania: ta opcja odcina autoryzację nieuwierzytelnionego ruchu do kodu aplikacji. W przypadku uwierzytelnionych żądań usługa App Service przekazuje również informacje uwierzytelniania w nagłówkach HTTP. Ta opcja zapewnia większą elastyczność obsługi żądań anonimowych. Umożliwia ona prezentowanie wielu dostawców logowania użytkownikom.

• Wymagaj uwierzytelniania: ta opcja odrzuca nieuwierzytelniony ruch do aplikacji. To odrzucenie może być akcją przekierowania do jednego ze skonfigurowanych dostawców tożsamości. W takich przypadkach klient przeglądarki jest przekierowywany do /.auth/login/<provider> wybranego dostawcy. Jeśli żądanie anonimowe pochodzi z natywnej aplikacji mobilnej, zwracana odpowiedź to HTTP 401 Unauthorized. Można również skonfigurować odrzucenie jako lub HTTP 401 Unauthorized HTTP 403 Forbidden dla wszystkich żądań.

  Uwaga

  Ograniczenie dostępu w ten sposób ma zastosowanie do wszystkich wywołań aplikacji, które mogą nie być pożądane w przypadku aplikacji, które chcą publicznie dostępnej strony głównej, jak w wielu aplikacjach jednostronicowych.

Magazyn tokenów

Usługa App Service udostępnia wbudowany magazyn tokenów, który jest repozytorium tokenów skojarzonych z użytkownikami aplikacji internetowych, interfejsów API lub natywnych aplikacji mobilnych. Po włączeniu uwierzytelniania u dowolnego dostawcy ten magazyn tokenów jest natychmiast dostępny dla aplikacji.

Rejestrowanie i śledzenie

Jeśli włączysz rejestrowanie aplikacji, ślady uwierzytelniania i autoryzacji są zbierane bezpośrednio w plikach dziennika. Jeśli zostanie wyświetlony błąd uwierzytelniania, którego nie oczekiwano, możesz wygodnie znaleźć wszystkie szczegóły, wyszukując istniejące dzienniki aplikacji.