Uwierzytelnianie i autoryzacja w usłudze Azure App Service i funkcjach Azure Functions

Usługa Azure App Service udostępnia wbudowane funkcje uwierzytelniania (logowania użytkowników) i autoryzacji (zapewniające dostęp do bezpiecznych danych). Te możliwości są czasami nazywane łatwym uwierzytelnianiem. Można ich używać do logowania użytkowników i uzyskiwania dostępu do danych, zapisując mały lub żaden kod w aplikacji internetowej, interfejs API RESTful, serwer mobilny i funkcje.

W tym artykule opisano, jak usługa App Service ułatwia uproszczenie uwierzytelniania i autoryzacji dla aplikacji.

Powody korzystania z uwierzytelniania wbudowanego

Aby zaimplementować uwierzytelnianie i autoryzację, możesz użyć powiązanych funkcji zabezpieczeń w wybranej strukturze internetowej lub pisać własne narzędzia. Zaimplementowanie bezpiecznego rozwiązania do uwierzytelniania i autoryzacji może wymagać znacznego nakładu pracy. Musisz przestrzegać najlepszych rozwiązań i standardów branżowych. Należy również upewnić się, że rozwiązanie jest aktualne dzięki najnowszym aktualizacjom zabezpieczeń, protokołu i przeglądarki.

Wbudowane możliwości usług App Service i Azure Functions mogą zaoszczędzić czas i wysiłek, zapewniając gotowe rozwiązanie uwierzytelniania z federacyjnymi dostawcami tożsamości, co pozwala skupić się na reszcie aplikacji.

Dzięki usłudze App Service możesz zintegrować możliwości uwierzytelniania z aplikacją internetową lub interfejsem API bez samodzielnego implementowania ich. Ta funkcja jest wbudowana bezpośrednio w platformę i nie wymaga żadnego określonego języka, zestawu SDK, wiedzy z zakresu zabezpieczeń ani kodu. Można ją zintegrować z wieloma dostawcami logowania, takimi jak Microsoft Entra, Facebook, Google i X.

Aplikacja może wymagać obsługi bardziej złożonych scenariuszy, takich jak integracja programu Visual Studio lub zgoda przyrostowa. Do obsługi tych scenariuszy jest dostępnych kilka rozwiązań uwierzytelniania. Aby dowiedzieć się więcej, zobacz Scenariusze uwierzytelniania i zalecenia.

Dostawcy tożsamości

Usługa App Service korzysta z tożsamości federacyjnej. Dostawca tożsamości firmy Microsoft lub innej firmy niż Microsoft 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	Poradnik krok po kroku
Microsoft Entra	/.auth/login/aad	Logowanie do platformy Microsoft Entra w usłudze App Service
Facebook	/.auth/login/facebook	Logowanie w usłudze App Service w serwisie Facebook
Google	/.auth/login/google	Logowanie przy użyciu Google w usłudze App Service
X	/.auth/login/x	Logowanie W usłudze App Service X
GitHub	/.auth/login/github	Logowanie do usługi App Service za pomocą GitHub
Apple	/.auth/login/apple	Logowanie w usłudze App Service za pośrednictwem logowania firmy Apple (wersja zapoznawcza)
Dowolny dostawca OpenID Connect	/.auth/login/<providerName>	Logowanie do programu OpenID Connect w usłudze App Service

Po skonfigurowaniu tej funkcji przy użyciu jednego z tych dostawców jego punkt końcowy logowania jest dostępny do uwierzytelniania użytkownika i weryfikacji tokenów uwierzytelniania od dostawcy. Możesz udostępnić swoim użytkownikom dowolną liczbę tych opcji logowania.

Zagadnienia dotyczące używania wbudowanego uwierzytelniania

Włączenie wbudowanego uwierzytelniania powoduje automatyczne przekierowanie wszystkich żądań do aplikacji do protokołu HTTPS, niezależnie od ustawienia konfiguracji usługi App Service w celu wymuszenia protokołu HTTPS. Można wyłączyć to automatyczne przekierowywanie przy użyciu ustawienia requireHttps w konfiguracji V2. Zalecamy jednak, aby nadal używać protokołu HTTPS i upewnić się, że żadne tokeny zabezpieczające nigdy nie są przesyłane za pośrednictwem niezabezpieczonych połączeń HTTP.

Usługę App Service można używać do uwierzytelniania z lub bez ograniczania dostępu do zawartości witryny i interfejsów API. Ustaw ograniczenia dostępu w sekcji Ustawienia>Uwierzytelnianie> aplikacji internetowej:Ustawienia uwierzytelniania

• Aby ograniczyć dostęp aplikacji tylko do uwierzytelnionych użytkowników, ustaw opcję Akcja, która ma być wykonywana, gdy żądanie nie zostanie uwierzytelnione w celu zalogowania się przy użyciu jednego ze skonfigurowanych dostawców tożsamości.
• Aby uwierzytelnić się, ale nie ograniczać dostępu, ustaw opcję Akcja, która ma być wykonywana, gdy żądanie nie jest uwierzytelnione, aby zezwolić na żądania anonimowe (bez akcji).

Ważne

Powinieneś przyznać każdej rejestracji aplikacji jej własne uprawnienia i zgodę. Unikaj udostępniania uprawnień między środowiskami przy użyciu oddzielnych rejestracji aplikacji dla oddzielnych miejsc wdrożenia. Podczas testowania nowego kodu ta praktyka może pomóc zapobiec problemom wpływającym na aplikację produkcyjną.

Jak to działa

Architektura funkcji

Składnik oprogramowania pośredniczącego uwierzytelniania i autoryzacji jest funkcją platformy działającej na tej samej maszynie wirtualnej co aplikacja. Po jej włączeniu każde przychodzące żądanie HTTP przechodzi przez ten składnik, zanim aplikacja go obsłuży.

Oprogramowanie pośredniczące platformy obsługuje kilka rzeczy dla aplikacji:

• Uwierzytelnia użytkowników i klientów przy użyciu określonych dostawców tożsamości
• Weryfikuje, przechowuje i odświeża tokeny OAuth wystawione przez skonfigurowanych dostawców 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. Można ją 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.

Architektura funkcji w systemie Windows (wdrażanie niekontenerowe)

Moduł uwierzytelniania i autoryzacji działa jako moduł natywny IIS w tej samej piaskownicy co aplikacja. Po jej włączeniu każde przychodzące żądanie HTTP przechodzi przez nie, zanim aplikacja go obsłuży.

Architektura funkcji w systemie Linux i kontenerach

Moduł uwierzytelniania i autoryzacji jest uruchamiany w oddzielnym kontenerze, który jest odizolowany od kodu aplikacji. Moduł używa wzorca ambasadora do interakcji z ruchem przychodzącym w celu wykonywania podobnych funkcji, jak w systemie Windows. Ponieważ nie jest ona uruchamiana w procesie, nie jest możliwa bezpośrednia integracja z określonymi strukturami językowymi. Jednak odpowiednie informacje wymagane przez aplikację są przekazywane w nagłówkach żądań.

Przepływ uwierzytelniania

Przepływ uwierzytelniania jest taki sam dla wszystkich dostawców. 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, dlatego jest nazywany również przepływem kierowanym przez serwer lub przepływem serwera.

  Ten przypadek dotyczy aplikacji przeglądarki i aplikacji mobilnych, które używają przeglądarki osadzonej do uwierzytelniania.

• Przy użyciu zestawu SDK dostawcy: aplikacja loguje użytkowników do dostawcy ręcznie. Następnie przesyła token uwierzytelniania do usługi App Service w celu weryfikacji. Ten proces jest zwykle w przypadku aplikacji bez przeglądarki, które nie mogą przedstawić użytkownikowi strony logowania dostawcy. Kod aplikacji zarządza procesem logowania, dlatego jest również nazywany przepływem kierowanym przez klienta lub przepływem klienta.

  Ten przypadek dotyczy interfejsów API REST, usługi Azure Functions i klientów przeglądarki JavaScript, a także aplikacji przeglądarki wymagających większej elastyczności w procesie logowania. Dotyczy to również natywnych aplikacji mobilnych, w których użytkownicy logują się przy użyciu zestawu SDK dostawcy.

Wywołania z zaufanej aplikacji przeglądarkowej w usłudze App Service do innego interfejsu API REST w usłudze App Service lub usłudze Azure Functions mogą być uwierzytelniane za pośrednictwem przepływu sterowanego przez serwer. Aby uzyskać więcej informacji, zobacz Dostosowywanie logowania i wylogowywania w usłudze Azure App Service.

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

Krok	Bez zestawu SDK dostawcy	Z użyciem zestawu SDK dostawcy
1. Zaloguj się do użytkownika	Dostawca przekierowuje klienta do /.auth/login/<provider>.	Kod klienta loguje użytkownika bezpośrednio za pomocą zestawu SDK dostawcy i otrzymuje token uwierzytelniania. Aby uzyskać więcej informacji, zobacz dokumentację dostawcy.
2. Przeprowadzanie po uwierzytelnianiu	Dostawca przekierowuje klienta do /.auth/login/<provider>/callback.	Kod klienta publikuje token od dostawcy w celu weryfikacji w /.auth/login/<provider>.
3. 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.
4. 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 nagłówku X-ZUMO-AUTH .

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

Zachowanie autoryzacji

W witrynie Azure Portal można skonfigurować usługę App Service z różnymi zachowaniami, gdy żądanie przychodzące nie jest uwierzytelnione. W poniższych sekcjach opisano opcje.

Ważne

Domyślnie ta funkcja zapewnia tylko uwierzytelnianie, a nie autoryzację. Aplikacja może nadal podejmować decyzje dotyczące autoryzacji, oprócz wszelkich kontroli skonfigurowanych w tym miejscu.

Dostęp ograniczony

• Zezwalaj na nieuwierzytelnione żądania: ta opcja przekazuje 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 to na przykład prezentowanie wielu dostawców logowania użytkownikom. Należy jednak napisać kod.

• Wymagaj uwierzytelniania: ta opcja odrzuca nieuwierzytelniony ruch do aplikacji. Określona akcja do wykonania jest określona w sekcji Żądania nieuwierzytelnione w dalszej części tego artykułu.

  Dzięki tej opcji nie musisz pisać żadnego kodu uwierzytelniania w aplikacji. Możesz obsługiwać bardziej precyzyjną autoryzację, taką jak autoryzacja specyficzna dla roli, sprawdzając oświadczenia użytkownika.

  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. Jeśli wymagane są wyjątki, należy skonfigurować wykluczone ścieżki w pliku konfiguracji.

  Uwaga

  Kiedy korzystasz z dostawcy tożsamości Microsoft dla użytkowników w swojej organizacji, domyślne zachowanie polega na tym, że każdy użytkownik w dzierżawie Microsoft Entra może zażądać tokenu dla Twojej aplikacji. Aplikację w usłudze Microsoft Entra można skonfigurować, jeśli chcesz ograniczyć dostęp do aplikacji do zdefiniowanego zestawu użytkowników. Usługa App Service oferuje również kilka podstawowych wbudowanych kontroli autoryzacji, które mogą pomóc w niektórych weryfikacjach. Aby dowiedzieć się więcej na temat autoryzacji w usłudze Microsoft Entra, zobacz Microsoft Entra authorization basics (Podstawy autoryzacji entra firmy Microsoft).

W przypadku korzystania z dostawcy tożsamości firmy Microsoft dla użytkowników w organizacji domyślne zachowanie polega na tym, że każdy użytkownik w dzierżawie firmy Microsoft Entra może zażądać tokenu dla aplikacji. Aplikację w usłudze Microsoft Entra można skonfigurować, jeśli chcesz ograniczyć dostęp do aplikacji do zdefiniowanego zestawu użytkowników. Usługa App Service oferuje również kilka podstawowych wbudowanych testów autoryzacji , które mogą pomóc w niektórych walidacjach. Aby dowiedzieć się więcej na temat autoryzacji w usłudze Microsoft Entra, zobacz Microsoft Entra authorization basics (Podstawy autoryzacji entra firmy Microsoft).

Niezautoryzowane żądania

• Znaleziono przekierowanie HTTP 302: zalecane dla stron internetowych: akcja przekierowuje użytkownika do jednego z skonfigurowanych dostawców tożsamości. W takich przypadkach klient przeglądarki jest przekierowywany do /.auth/login/<provider> wybranego dostawcy.
• HTTP 401 Brak autoryzacji: zalecane dla interfejsów API: zwraca HTTP 401 Unauthorized odpowiedź, jeśli żądanie anonimowe pochodzi z natywnej aplikacji mobilnej. Można również skonfigurować odrzucenie tak, aby dotyczyło HTTP 401 Unauthorized wszystkich żądań.
• Http 403 Zabronione: konfiguruje odrzucenie tak, aby HTTP 403 Forbidden dotyczyło wszystkich żądań.
• Nie znaleziono protokołu HTTP 404: umożliwia skonfigurowanie odrzucenia HTTP 404 Not found dla wszystkich żądań.

Magazyn tokenów

Usługa App Service udostępnia wbudowany magazyn tokenów. Magazyn tokenów to 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.

Jeśli kod aplikacji musi uzyskiwać dostęp do danych od tych dostawców w imieniu użytkownika, zazwyczaj musisz napisać kod do zbierania, przechowywania i odświeżania tych tokenów w aplikacji. Akcje mogą obejmować:

• Opublikuj na osi czasu uwierzytelnionego użytkownika w serwisie Facebook.
• Odczytywanie danych firmowych użytkownika przy użyciu interfejsu API programu Microsoft Graph.

W magazynie tokenów możesz łatwo pobrać tokeny wtedy, gdy ich potrzebujesz, i poinformować usługę App Service, aby je odświeżyła, gdy staną się nieprawidłowe.

Tokeny identyfikatorów, tokeny dostępu i tokeny odświeżania są buforowane dla uwierzytelnionej sesji. Tylko skojarzony użytkownik może uzyskać do nich dostęp.

Jeśli nie musisz pracować z tokenami w aplikacji, możesz wyłączyć magazyn tokenów na stronieUwierzytelnianie> aplikacji.

Rejestrowanie i śledzenie

Jeśli włączysz rejestrowanie aplikacji, ślady uwierzytelniania i autoryzacji są wyświetlane 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.

Jeśli włączono śledzenie żądań, które zakończyło się niepowodzeniem, zobaczysz dokładnie, jaką rolę może odgrywać moduł uwierzytelniania i autoryzacji w żądaniu, który zakończył się niepowodzeniem. W dziennikach śledzenia poszukaj odwołań do modułu o nazwie EasyAuthModule_32/64.

Mitigacja fałszerstwa zapytań między witrynami

Uwierzytelnianie usługi App Service ogranicza fałszowanie żądań między witrynami, przez analizę żądań klientów według poniższych kryteriów.

• Jest to POST żądanie uwierzytelnione za pośrednictwem ciasteczka sesji.
• Żądanie pochodzi ze znanej przeglądarki określonej przez nagłówek HTTP User-Agent .
• Brakuje nagłówka HTTP Origin lub HTTP Referer, albo nagłówek nie znajduje się na skonfigurowanej liście zatwierdzonych domen zewnętrznych do przekierowania.
• Brakuje nagłówka HTTP Origin lub nie znajduje się on na skonfigurowanej liście współdzielenia zasobów między źródłami (CORS).

Gdy żądanie spełnia wszystkie te warunki, uwierzytelnianie usługi App Service automatycznie je odrzuca. Tę logikę ograniczania ryzyka można obejść, dodając domenę zewnętrzną do listy przekierowań w obszarze Ustawienia>Uwierzytelnianie Edytuj ustawienia>uwierzytelniania>Dozwolone zewnętrzne adresy URL przekierowania.

Zagadnienia dotyczące korzystania z usługi Azure Front Door

Jeśli używasz usługi Azure App Service z uwierzytelnianiem za usługą Azure Front Door lub innymi zwrotnymi serwerami proxy, rozważ następujące kroki.

Wyłącz buforowanie usługi Azure Front Door

Wyłączanie buforowania Azure Front Door dla przepływu uwierzytelniania.

Używanie punktu końcowego usługi Azure Front Door na potrzeby przekierowań

Usługa App Service jest zwykle niedostępna bezpośrednio, gdy jest udostępniana przez Azure Front Door. Można temu zapobiec, na przykład, uwidaczniając usługę App Service przy użyciu usługi Azure Private Link w usłudze Azure Front Door Premium. Aby uniemożliwić procesowi uwierzytelniania bezpośrednie przekierowywanie ruchu z powrotem do usługi App Service. Aby uzyskać więcej informacji, sprawdź Identyfikator URI przekierowania.

Upewnij się, że usługa App Service używa odpowiedniego adresu URL przekierowania

W niektórych konfiguracjach usługa App Service używa w pełni kwalifikowanej nazwy domeny (FQDN) jako identyfikatora URI przekierowania zamiast nazwy FQDN usługi Azure Front Door. Ta konfiguracja powoduje problem, gdy klient jest przekierowywany do usługi App Service zamiast usługi Azure Front Door. Aby dokonać zmiany, ustaw forwardProxy na Standard, aby App Service uwzględniała nagłówek ustawiony przez Azure Front Door.

Inne odwrotne serwery proxy, takie jak usługa Azure Application Gateway lub produkty firmy innej niż Microsoft, mogą używać różnych nagłówków i potrzebować innego forwardProxy ustawienia.

Nie można zmienić forwardProxy konfiguracji przy użyciu witryny Azure Portal. Musisz użyć az rest.

Eksportowanie ustawień

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

Aktualizowanie ustawień

Szukać:

"httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

Upewnij się, że convention jest ustawiony na Standard w celu uwzględnienia nagłówka X-Forwarded-Host używanego przez Azure Front Door.

Ustawienia importu

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

Powiązana zawartość

Aby uzyskać więcej informacji na temat uwierzytelniania usługi App Service, zobacz:

• Konfigurowanie aplikacji App Service lub Azure Functions do korzystania z logowania w usłudze Microsoft Entra
• Dostosowywanie logowania i wylogowywania w usłudze Azure App Service
• Praca z tokenami OAuth w uwierzytelnianiu w usłudze Azure App Service
• Praca z tożsamościami użytkowników w uwierzytelnianiu usługi Azure App Service
• Konfiguracja oparta na plikach w uwierzytelnianiu usługi Azure App Service

Przykłady można znaleźć tutaj:

• Szybki start: dodawanie uwierzytelniania aplikacji do aplikacji internetowej uruchomionej w usłudze Azure App Service
• Samouczek : Uwierzytelnianie i autoryzowanie użytkowników od końca do końca w usłudze Azure App Service
• Integracja platformy .NET Core z usługą Azure AppService Easy Auth (zawartość usługi GitHub innej niż Microsoft)
• Włączenie uwierzytelniania w usłudze Azure App Service z platformą .NET Core (treść spoza Microsoftu na GitHubie)