Udostępnij za pośrednictwem

Uwierzytelnianie i autoryzacja w usługach aplikacja systemu Azure i Azure Functions

  • Artykuł

Uwaga

Od 1 czerwca 2024 r. wszystkie nowo utworzone aplikacje usługi App Service będą miały możliwość wygenerowania unikatowej domyślnej nazwy hosta przy użyciu konwencji <app-name>-<random-hash>.<region>.azurewebsites.netnazewnictwa . Istniejące nazwy aplikacji pozostaną niezmienione.

Przykład: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Aby uzyskać więcej informacji, zapoznaj się z unikatową domyślną nazwą hosta zasobu usługi App Service.

usługa aplikacja systemu Azure zapewnia wbudowane funkcje uwierzytelniania i autoryzacji (czasami określane jako "Easy Auth"), dzięki czemu można logować użytkowników i uzyskiwać dostęp do danych, zapisując minimalny lub żaden kod w aplikacji internetowej, interfejsIE API RESTful i zapleczu dla urządzeń przenośnych, a także Azure Functions. W tym artykule opisano, jak usługa App Service ułatwia uproszczenie uwierzytelniania i autoryzacji dla aplikacji.

Dlaczego warto używać wbudowanego uwierzytelniania?

Nie musisz używać tej funkcji do uwierzytelniania i autoryzacji. Możesz użyć powiązanych funkcji zabezpieczeń w wybranej strukturze internetowej lub pisać własne narzędzia. Należy jednak upewnić się, że rozwiązanie jest aktualne dzięki najnowszym aktualizacjom zabezpieczeń, protokołu i przeglądarki.

Zaimplementowanie bezpiecznego rozwiązania do uwierzytelniania (użytkowników logujący się) i autoryzacji (zapewnienie dostępu do bezpiecznych danych) może wymagać znacznego nakładu pracy. Musisz pamiętać, aby przestrzegać najlepszych rozwiązań i standardów branżowych oraz zapewnić aktualność implementacji. 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.
  • Jest ona wbudowana bezpośrednio w platformę i nie wymaga żadnego konkretnego języka, zestawu SDK, wiedzy na temat zabezpieczeń, a nawet żadnego kodu do użycia.
  • Można zintegrować z wieloma dostawcami logowania. Na przykład Microsoft Entra, Facebook, Google, X.

Aplikacja może wymagać obsługi bardziej złożonych scenariuszy, takich jak integracja programu Visual Studio lub zgoda przyrostowa. Istnieje kilka różnych rozwiązań uwierzytelniania dostępnych do obsługi tych scenariuszy. Aby dowiedzieć się więcej, przeczytaj Scenariusze obsługi tożsamości.

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
Microsoft Entra /.auth/login/aad Identyfikator logowania platformy Microsoft Entra w usłudze 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/x Logowanie do usługi App Service X
GitHub /.auth/login/github Identyfikator logowania usługi GitHub w usłudze App Service
Logowanie się przy użyciu firmy Apple /.auth/login/apple Logowanie w usłudze App Service przy użyciu 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 tej funkcji spowoduje 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 to wyłączyć za requireHttps pomocą ustawienia w konfiguracji w wersji 2. Zalecamy jednak trzymanie się protokołu HTTPS i należy upewnić się, że żadne tokeny zabezpieczające nigdy nie są przesyłane za pośrednictwem niezabezpieczonych połączeń HTTP.

Usługa App Service może służyć do uwierzytelniania za pomocą interfejsu API lub bez ograniczania dostępu do zawartości witryny i interfejsów API. Ograniczenia dostępu można ustawić w sekcji Ustawienia uwierzytelniania>aplikacji internetowej. 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 do wykonania, gdy żądanie nie jest uwierzytelniane na wartość "Zezwalaj na żądania anonimowe (bez akcji).

Ważne

Każda rejestracja aplikacji powinna mieć 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

Przepływ uwierzytelniania

Zachowanie autoryzacji

Magazyn tokenów

Rejestrowanie i śledzenie

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 nie przed obsłużenie przez aplikację.

Diagram architektury przedstawiający żądania przechwycone przez proces w piaskownicy lokacji, który współdziała z dostawcami tożsamości przed zezwoleniem na ruch do wdrożonej lokacji

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 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.

Architektura funkcji w systemie Windows (wdrażanie niekontenerowe)

Moduł uwierzytelniania i autoryzacji działa jako natywny moduł usług IIS w tej samej piaskownicy co aplikacja. Po jej włączeniu każde przychodzące żądanie HTTP przechodzi przez nie przed obsłużenie przez aplikację.

Architektura funkcji w systemie Linux i kontenerach

Moduł uwierzytelniania i autoryzacji jest uruchamiany w oddzielnym kontenerze izolowanym od kodu aplikacji. Korzystając ze wzorca ambasadora, współdziała on 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 istotne informacje wymagane przez aplikację są przekazywane przy użyciu nagłówków żądań, jak wyjaśniono poniżej.

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. Jest to zwykle przypadek 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.
  • 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, dlatego jest nazywany również przepływem skierowanym 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, które wymagają większej elastyczności w procesie logowania. Dotyczy to również natywnych aplikacji mobilnych, które loguje użytkowników przy użyciu zestawu SDK dostawcy.

Wywołania z zaufanej aplikacji przeglądarki w usłudze App Service do innego interfejsu API REST w usłudze App Service lub usługi Azure Functions można uwierzytelniać przy użyciu przepływu kierowanego przez serwer. Aby uzyskać więcej informacji, zobacz Dostosowywanie logów i wylogowywanie.

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

Krok Bez zestawu SDK dostawcy Zestaw SDK dostawcy
1. 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.
2. Po uwierzytelnianiu Dostawca przekierowuje klienta do /.auth/login/<provider>/callback. Kod klienta publikuje token od dostawcy do /.auth/login/<provider> w celu weryfikacji.
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 X-ZUMO-AUTH nagłówku.

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

Ważne

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

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

Ograniczanie dostępu

  • 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 to na przykład prezentowanie wielu dostawców logowania użytkownikom. Należy jednak napisać kod.

  • Wymagaj uwierzytelniania Ta opcja odrzuci nieuwierzytelniony ruch do aplikacji. Konkretna akcja do wykonania jest określona w sekcji Żądania nieuwierzytelnione .

    Dzięki tej opcji nie musisz pisać żadnego kodu uwierzytelniania w aplikacji. Bardziej precyzyjna autoryzacja, taka jak autoryzacja specyficzna dla roli, może być obsługiwana przez sprawdzenie oświadczeń użytkownika (zobacz Uzyskiwanie dostępu do oświadczeń użytkowników).

    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.

    Uwaga

    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 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).

Nieuwierzytelnione żądania

  • Znaleziono przekierowanie HTTP 302: zalecane dla witryn internetowych Akcja Przekierowania do jednego ze 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 w przypadku interfejsów API Jeśli żądanie anonimowe pochodzi z natywnej aplikacji mobilnej, zwracana odpowiedź to HTTP 401 Unauthorized. Możesz również skonfigurować odrzucenie jako element HTTP 401 Unauthorized dla wszystkich żądań.
  • Http 403 Zabronione Konfiguruje odrzucenie jako dla HTTP 403 Forbidden wszystkich żądań.
  • Http 404 Nie znaleziono Konfiguruje odrzucenie jako element HTTP 404 Not found dla wszystkich żądań.

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. Jeśli kod aplikacji musi uzyskiwać dostęp do danych od tych dostawców w imieniu użytkownika, takich jak:

  • publikowanie na osi czasu uwierzytelnioowanego użytkownika w serwisie Facebook
  • odczytywanie danych firmowych użytkownika przy użyciu interfejsu API programu Microsoft Graph

Zazwyczaj należy napisać kod, aby zbierać, przechowywać i odświeżać te tokeny w aplikacji. W magazynie tokenów wystarczy pobrać tokeny , gdy są one potrzebne, i poinformować usługę App Service, aby odświeżyła je , gdy staną się nieprawidłowe.

Tokeny identyfikatorów, tokeny dostępu i tokeny odświeżania są buforowane dla uwierzytelnionej sesji i są dostępne tylko przez skojarzonego użytkownika.

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

Rejestrowanie i śledzenie

Jeśli włączysz rejestrowanie aplikacji, zobaczysz ślady uwierzytelniania i autoryzacji 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ę mógł odegrać 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.

Ograniczanie ryzyka fałszowania żądań międzylokacyjnych

Uwierzytelnianie usługi App Service ogranicza csrF, sprawdzając żądania klientów pod kątem następujących warunków:

  • Jest to żądanie POST uwierzytelnione przy użyciu pliku cookie sesji.
  • Żądanie pochodzi ze znanej przeglądarki (określonej przez nagłówek HTTP User-Agent ).
  • Brak nagłówka HTTP Origin lub HTTP Referer lub nie znajduje się na skonfigurowanej liście zatwierdzonych domen zewnętrznych na potrzeby przekierowania.
  • Brak nagłówka HTTP Origin lub nie znajduje się na skonfigurowanej liście źródeł 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ń do pozycji Ustawienia uwierzytelniania>Edytuj ustawienia>uwierzytelniania Dozwolone zewnętrzne adresy URL przekierowania.

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

W przypadku korzystania z usługi aplikacja systemu Azure z uwierzytelnianiem za usługą Azure Front Door lub innymi zwrotnymi serwerami proxy należy wziąć pod uwagę kilka dodatkowych kwestii.

  • Wyłącz buforowanie usługi Front Door dla przepływu pracy uwierzytelniania.

  • Użyj punktu końcowego usługi Front Door na potrzeby przekierowań.

    Usługa App Service jest zwykle niedostępna bezpośrednio w przypadku uwidocznienia za pośrednictwem usługi Azure Front Door. Można temu zapobiec, na przykład ujawniając usługę App Service za pośrednictwem usługi Private Link w usłudze Azure Front Door Premium. Aby uniemożliwić przepływowi pracy uwierzytelniania przekierowanie ruchu z powrotem do usługi App Service, należy skonfigurować aplikację w celu przekierowania z powrotem do https://<front-door-endpoint>/.auth/login/<provider>/callbackusługi .

  • Upewnij się, że usługa App Service używa odpowiedniego identyfikatora URI przekierowania

    W niektórych konfiguracjach usługa App Service używa nazwy FQDN usługi App Service jako identyfikatora URI przekierowania zamiast nazwy FQDN usługi Front Door. Spowoduje to problem, gdy klient jest przekierowywany do usługi App Service zamiast usługi Front Door. Aby to zmienić, należy ustawić ustawienie tak, forwardProxy aby Standard usługa App Service uwzględniała nagłówek ustawiony przez usługę X-Forwarded-Host Azure Front Door.

    Inne odwrotne serwery proxy, takie jak aplikacja systemu Azure Gateway lub produkty innych firm, mogą używać różnych nagłówków i potrzebować innego ustawienia forwardProxy.

    Tej konfiguracji nie można wykonać już w witrynie Azure Portal i należy wykonać za pośrednictwem polecenia az rest:

    Ustawienia eksportu

    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ń

    Wyszukaj

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

    i upewnij się, że convention ustawiono wartość w celu Standard przestrzegania nagłówka używanego przez usługę X-Forwarded-Host 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

Więcej zasobów

Przykłady: