Konfigurowanie aplikacji App Service lub Azure Functions do korzystania z logowania w usłudze Microsoft Entra

  • Artykuł

Wybierz innego dostawcę uwierzytelniania, aby przejść do niego.

W tym artykule pokazano, jak skonfigurować uwierzytelnianie dla usługi aplikacja systemu Azure lub usługi Azure Functions, aby aplikacja logować użytkowników przy użyciu identyfikatora Platforma tożsamości Microsoft (Microsoft Entra ID) jako dostawcy uwierzytelniania.

Funkcja uwierzytelniania usługi App Service może automatycznie utworzyć rejestrację aplikacji przy użyciu Platforma tożsamości Microsoft. Możesz również użyć rejestracji utworzonej oddzielnie przez Ciebie lub administratora katalogu.

Uwaga

Opcja automatycznego tworzenia nowej rejestracji nie jest dostępna dla chmur dla instytucji rządowych ani w przypadku korzystania z usługi [Microsoft Entra ID dla klientów (wersja zapoznawcza)]. Zamiast tego zdefiniuj rejestrację oddzielnie.

Opcja 1. Automatyczne tworzenie nowej rejestracji aplikacji

Użyj tej opcji, chyba że musisz utworzyć rejestrację aplikacji oddzielnie. Rejestrację aplikacji można dostosować w identyfikatorze Entra firmy Microsoft po jej utworzeniu.

  1. Zaloguj się do witryny Azure Portal i przejdź do aplikacji.

  2. Wybierz pozycję Uwierzytelnianie w menu po lewej stronie. Wybierz pozycję Dodaj dostawcę tożsamości.

  3. Wybierz pozycję Microsoft z listy rozwijanej Dostawca tożsamości. Opcja utworzenia nowej rejestracji jest domyślnie zaznaczona. Możesz zmienić nazwę rejestracji lub obsługiwane typy kont.

    Wpis tajny klienta zostanie utworzony i zapisany jako ustawienie aplikacji slot-sticky o nazwie MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Możesz zaktualizować to ustawienie później, aby użyć odwołań usługi Key Vault, jeśli chcesz zarządzać wpisem tajnym w usłudze Azure Key Vault.

  4. Jeśli jest to pierwszy dostawca tożsamości skonfigurowany dla aplikacji, zostanie również wyświetlony monit z sekcją Ustawień uwierzytelniania usługi App Service. W przeciwnym razie możesz przejść do następnego kroku.

    Te opcje określają sposób, w jaki aplikacja odpowiada na nieuwierzytelnione żądania, a domyślne opcje przekierują wszystkie żądania, aby zalogować się przy użyciu tego nowego dostawcy. Możesz teraz zmienić to zachowanie lub dostosować te ustawienia później z głównego ekranu uwierzytelniania , wybierając pozycję Edytuj obok pozycji Ustawienia uwierzytelniania. Aby dowiedzieć się więcej o tych opcjach, zobacz Przepływ uwierzytelniania.

  5. (Opcjonalnie) Wybierz pozycję Dalej: Uprawnienia i dodaj wszystkie uprawnienia programu Microsoft Graph wymagane przez aplikację. Zostaną one dodane do rejestracji aplikacji, ale można je również zmienić później.

  6. Wybierz Dodaj.

Teraz możesz użyć Platforma tożsamości Microsoft do uwierzytelniania w aplikacji. Dostawca zostanie wyświetlony na ekranie Uwierzytelnianie . Z tego miejsca możesz edytować lub usunąć tę konfigurację dostawcy.

Aby zapoznać się z przykładem konfigurowania logowania microsoft Entra dla aplikacji internetowej, która uzyskuje dostęp do usługi Azure Storage i programu Microsoft Graph, zobacz ten samouczek.

Opcja 2. Użyj istniejącej rejestracji utworzonej oddzielnie

Uwierzytelnianie usługi App Service można skonfigurować tak, aby używało istniejącej rejestracji aplikacji. Następujące sytuacje to najczęstsze przypadki użycia istniejącej rejestracji aplikacji:

  • Twoje konto nie ma uprawnień do tworzenia rejestracji aplikacji w dzierżawie firmy Microsoft Entra.
  • Chcesz użyć rejestracji aplikacji z innej dzierżawy firmy Microsoft Entra niż ta, w której znajduje się twoja aplikacja.
  • Opcja utworzenia nowej rejestracji nie jest dostępna dla chmur dla instytucji rządowych.

Krok 1. Tworzenie rejestracji aplikacji w usłudze Microsoft Entra ID dla aplikacji usługi App Service

Podczas tworzenia rejestracji aplikacji zbierz następujące informacje, które będą potrzebne później podczas konfigurowania uwierzytelniania w aplikacji usługi App Service:

  • Client ID
  • Identyfikator dzierżawy
  • Klucz tajny klienta (opcjonalny, ale zalecany)
  • URI identyfikatora aplikacji

Instrukcje dotyczące tworzenia rejestracji aplikacji zależą od tego, czy używasz dzierżawy pracowników, czy dzierżawy klienta. Użyj poniższych kart, aby wybrać odpowiedni zestaw instrukcji dla danego scenariusza.

Aby zarejestrować aplikację, wykonaj następujące kroki:

  1. Zaloguj się do witryny Azure Portal, wyszukaj i wybierz pozycję App Services, a następnie wybierz aplikację. Zanotuj adres URL aplikacji. Użyjesz go do skonfigurowania rejestracji aplikacji Microsoft Entra.

  2. Przejdź do dzierżawy w portalu:

    W menu portalu wybierz pozycję Microsoft Entra ID. Jeśli używana dzierżawa różni się od używanej do konfigurowania aplikacji usługi App Service, musisz najpierw zmienić katalogi .

  3. Na ekranie "Przegląd" zanotuj identyfikator dzierżawy, a także domenę podstawową.

  4. W obszarze nawigacji po lewej stronie wybierz pozycję Rejestracje aplikacji> Nowa rejestracja.

  5. Na stronie Rejestrowanie aplikacji wprowadź nazwę rejestracji aplikacji.

  6. W obszarze Obsługiwane typy kont wybierz typ konta, który może uzyskać dostęp do tej aplikacji.

  7. W sekcji Identyfikatory URI przekierowania wybierz pozycję Sieć Web dla platformy i wpisz <app-url>/.auth/login/aad/callback. Na przykład https://contoso.azurewebsites.net/.auth/login/aad/callback.

  8. Wybierz pozycję Zarejestruj.

  9. Po utworzeniu rejestracji aplikacji skopiuj identyfikator aplikacji (klienta) i identyfikator katalogu (dzierżawy) na później.

  10. W obszarze nawigacji po lewej stronie wybierz pozycję Uwierzytelnianie. W obszarze Niejawne udzielanie i przepływy hybrydowe włącz tokeny identyfikatorów, aby zezwolić na logowanie użytkowników openID Połączenie z usługi App Service. Wybierz pozycję Zapisz.

  11. (Opcjonalnie) W obszarze nawigacji po lewej stronie wybierz pozycję Znakowanie i właściwości. W polu Adres URL strony głównej wprowadź adres URL aplikacji usługi App Service i wybierz pozycję Zapisz.

  12. W obszarze nawigacji po lewej stronie wybierz pozycję Uwidaczniaj interfejs API>Dodaj>zapisz. Ta wartość unikatowo identyfikuje aplikację, gdy jest używana jako zasób, co pozwala na żądanie tokenów, które udzielają dostępu. Jest on używany jako prefiks dla tworzonych zakresów.

    W przypadku aplikacji z jedną dzierżawą można użyć wartości domyślnej, która znajduje się w postaci api://<application-client-id>. Można również określić bardziej czytelny identyfikator URI, taki jak https://contoso.com/api na podstawie jednej ze zweryfikowanych domen dla dzierżawy. W przypadku aplikacji wielodostępnej należy podać niestandardowy identyfikator URI. Aby dowiedzieć się więcej na temat akceptowanych formatów identyfikatorów URI identyfikatorów aplikacji, zobacz dokumentację najlepszych rozwiązań dotyczących rejestracji aplikacji.

  13. Wybierz Dodaj zakres.

    1. W polu Nazwa zakresu wprowadź user_impersonation.
    2. W KtoTo może wyrazić zgodę, wybierz pozycję Administracja i użytkowników, jeśli chcesz zezwolić użytkownikom na wyrażanie zgody na ten zakres.
    3. W polach tekstowych wprowadź nazwę zakresu zgody i opis, który użytkownicy mają zobaczyć na stronie zgody. Na przykład wprowadź nazwę aplikacji> programu Access<.
    4. Wybierz Dodaj zakres.

  14. (Opcjonalnie) Aby utworzyć klucz tajny klienta:

    1. W obszarze nawigacji po lewej stronie wybierz pozycję Certyfikaty i wpisy tajne Klienta Wpisy>tajne>Nowego klienta.
    2. Wprowadź opis i wygaśnięcie, a następnie wybierz pozycję Dodaj.
    3. W polu Wartość skopiuj wartość wpisu tajnego klienta. Po przejściu z tej strony nie będzie ona ponownie wyświetlana.

  15. (Opcjonalnie) Aby dodać wiele adresów URL odpowiedzi, wybierz pozycję Uwierzytelnianie.

  16. Zakończ konfigurowanie rejestracji aplikacji:

    W przypadku dzierżawy pracowników nie są wymagane żadne inne kroki.

Krok 2. Włączanie identyfikatora Entra firmy Microsoft w aplikacji usługi App Service

  1. Zaloguj się do witryny Azure Portal i przejdź do aplikacji.

  2. W obszarze nawigacji po lewej stronie wybierz pozycję Uwierzytelnianie>Dodaj dostawcę>tożsamości Microsoft.

  3. Wybierz typ dzierżawy utworzonej rejestracji aplikacji.

  4. Skonfiguruj aplikację tak, aby korzystała z utworzonej rejestracji, korzystając z instrukcji dotyczących odpowiedniego typu dzierżawy:

    W polu Typ rejestracji aplikacji wybierz jedną z następujących pozycji:

    • Wybierz istniejącą rejestrację aplikacji w tym katalogu: wybierz rejestrację aplikacji z bieżącej dzierżawy i automatycznie zbierz niezbędne informacje o aplikacji. System podejmie próbę utworzenia nowego wpisu tajnego klienta przed rejestracją aplikacji i automatycznie skonfiguruje aplikację do jej używania. Domyślny adres URL wystawcy jest ustawiany na podstawie obsługiwanych typów kont skonfigurowanych w rejestracji aplikacji. Jeśli zamierzasz zmienić tę wartość domyślną, zapoznaj się z poniższą tabelą.
    • Podaj szczegóły istniejącej rejestracji aplikacji: określ szczegóły rejestracji aplikacji z innej dzierżawy lub jeśli twoje konto nie ma uprawnień w bieżącej dzierżawie do wykonywania zapytań dotyczących rejestracji. W przypadku tej opcji należy ręcznie wypełnić wartości konfiguracji zgodnie z poniższą tabelą.

    Punkt końcowy uwierzytelniania dzierżawcy pracowników powinien być wartością specyficzną dla środowiska chmury. Na przykład dzierżawa pracowników na globalnej platformie Azure używahttps://login.microsoftonline.com" "; jako punkt końcowy uwierzytelniania. Zanotuj wartość punktu końcowego uwierzytelniania, ponieważ jest ona potrzebna do utworzenia odpowiedniego adresu URL wystawcy.

    Podczas bezpośredniego wypełniania szczegółów konfiguracji użyj wartości zebranych podczas procesu tworzenia rejestracji aplikacji:

    Pole opis
    Identyfikator aplikacji (klient) Użyj identyfikatora aplikacji (klienta) rejestracji aplikacji.
    Klucz tajny klienta Użyj wpisu tajnego klienta wygenerowanego podczas rejestracji aplikacji. W przypadku klucza tajnego klienta używany jest przepływ hybrydowy, a usługa App Service zwróci tokeny dostępu i odświeżania. Gdy klucz tajny klienta nie jest ustawiony, jest używany niejawny przepływ i zwracany jest tylko token identyfikatora. Te tokeny są wysyłane przez dostawcę i przechowywane w magazynie tokenów uwierzytelniania usługi App Service.
    Adres URL wystawcy Użyj <authentication-endpoint>/<tenant-id>/v2.0elementu i zastąp< wartość authentication-endpoint punktem końcowym> uwierzytelniania określonym w poprzednim kroku dla typu dzierżawy i środowiska chmury, zastępując również <identyfikator> dzierżawy identyfikatorem katalogu (dzierżawy), w którym utworzono rejestrację aplikacji. W przypadku aplikacji korzystających z usługi Azure AD w wersji 1 pomiń /v2.0 adres URL.

    Ta wartość służy do przekierowywania użytkowników do właściwej dzierżawy firmy Microsoft Entra, a także do pobierania odpowiednich metadanych w celu określenia odpowiednich kluczy podpisywania tokenu i wartości oświadczenia wystawcy tokenu na przykład. Każda konfiguracja inna niż punkt końcowy specyficzny dla dzierżawy będzie traktowana jako wielodostępna. W konfiguracjach z wieloma dzierżawami nie jest wykonywana żadna walidacja wystawcy lub identyfikatora dzierżawy przez system. Te testy powinny być w pełni obsługiwane w logice autoryzacji aplikacji.
    Dozwolone grupy odbiorców tokenów To pole jest opcjonalne. Skonfigurowany identyfikator aplikacji (klienta) jest zawsze niejawnie uznawany za dozwolonych odbiorców. Jeśli aplikacja reprezentuje interfejs API, który będzie wywoływany przez innych klientów, należy również dodać identyfikator URI identyfikatora aplikacji skonfigurowany podczas rejestracji aplikacji. Na liście dozwolonych odbiorców jest łącznie 500 znaków.

    Wpis tajny klienta będzie przechowywany jako ustawienie aplikacji slot-sticky o nazwie MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Możesz zaktualizować to ustawienie później, aby użyć odwołań usługi Key Vault, jeśli chcesz zarządzać wpisem tajnym w usłudze Azure Key Vault.

  5. Jeśli jest to pierwszy dostawca tożsamości skonfigurowany dla aplikacji, zostanie również wyświetlony monit z sekcją Ustawień uwierzytelniania usługi App Service. W przeciwnym razie możesz przejść do następnego kroku.

    Te opcje określają sposób, w jaki aplikacja odpowiada na nieuwierzytelnione żądania, a domyślne opcje przekierują wszystkie żądania, aby zalogować się przy użyciu tego nowego dostawcy. Możesz teraz zmienić to zachowanie lub dostosować te ustawienia później z głównego ekranu uwierzytelniania , wybierając pozycję Edytuj obok pozycji Ustawienia uwierzytelniania. Aby dowiedzieć się więcej o tych opcjach, zobacz Przepływ uwierzytelniania.

  6. Wybierz Dodaj.

Teraz możesz użyć Platforma tożsamości Microsoft do uwierzytelniania w aplikacji. Dostawca zostanie wyświetlony na ekranie Uwierzytelnianie . Z tego miejsca możesz edytować lub usunąć tę konfigurację dostawcy.

Autoryzowanie żądań

Domyślnie uwierzytelnianie usługi App Service obsługuje tylko uwierzytelnianie, określając, czy obiekt wywołujący jest tym, kim są. Autoryzacja, określenie, czy obiekt wywołujący powinien mieć dostęp do niektórych zasobów, to dodatkowy krok poza uwierzytelnianiem. Więcej informacji na temat tych pojęć można uzyskać w Platforma tożsamości Microsoft podstawach autoryzacji.

Aplikacja może podejmować decyzje dotyczące autoryzacji w kodzie. Uwierzytelnianie usługi App Service zapewnia wbudowane kontrole, które mogą pomóc, ale mogą nie być wystarczające, aby pokryć potrzeby autoryzacji aplikacji.

Napiwek

Aplikacje wielodostępne powinny weryfikować wystawcę i identyfikator dzierżawy żądania w ramach tego procesu, aby upewnić się, że wartości są dozwolone. Po skonfigurowaniu uwierzytelniania usługi App Service dla scenariusza z wieloma dzierżawami nie sprawdza, z której dzierżawy pochodzi żądanie. Aplikacja może być ograniczona do określonych dzierżaw, na podstawie tego, czy organizacja zarejestrowała się w usłudze, na przykład. Zapoznaj się ze wskazówkami dotyczącymi Platforma tożsamości Microsoft z wieloma dzierżawami.

Wykonywanie walidacji z poziomu kodu aplikacji

Podczas przeprowadzania kontroli autoryzacji w kodzie aplikacji możesz skorzystać z informacji o oświadczeniach udostępnianych przez uwierzytelnianie usługi App Service. Wstrzykiwany x-ms-client-principal nagłówek zawiera obiekt JSON zakodowany w formacie Base64 z oświadczeniami określonymi w obiekcie wywołującym. Domyślnie te oświadczenia przechodzą przez mapowanie oświadczeń, więc nazwy oświadczeń mogą nie zawsze być zgodne z tym, co można zobaczyć w tokenie. Na przykład oświadczenie tid jest mapowane na http://schemas.microsoft.com/identity/claims/tenantid zamiast tego.

Możesz również pracować bezpośrednio z bazowym tokenem dostępu z wstrzykniętego x-ms-token-aad-access-token nagłówka.

Korzystanie z wbudowanych zasad autoryzacji

Utworzona rejestracja aplikacji uwierzytelnia żądania przychodzące dla dzierżawy firmy Microsoft Entra. Domyślnie umożliwia ona również każdemu w dzierżawie uzyskiwanie dostępu do aplikacji, co jest odpowiednie w przypadku wielu aplikacji. Jednak niektóre aplikacje muszą jeszcze bardziej ograniczyć dostęp, podejmując decyzje dotyczące autoryzacji. Kod aplikacji jest często najlepszym miejscem do obsługi niestandardowej logiki autoryzacji. Jednak w przypadku typowych scenariuszy Platforma tożsamości Microsoft zapewnia wbudowane kontrole, których można użyć do ograniczenia dostępu.

W tej sekcji pokazano, jak włączyć wbudowane kontrole przy użyciu interfejsu API uwierzytelniania usługi App Service w wersji 2. Obecnie jedynym sposobem skonfigurowania tych wbudowanych testów jest użycie szablonów usługi Azure Resource Manager lub interfejsu API REST.

W obiekcie interfejsu API konfiguracja dostawcy tożsamości Firmy Microsoft Entra zawiera sekcję validationdefaultAuthorizationPolicy , która może zawierać obiekt, jak w następującej strukturze:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Właściwości opis
defaultAuthorizationPolicy Grupowanie wymagań, które należy spełnić w celu uzyskania dostępu do aplikacji. Dostęp jest udzielany w oparciu o wartość logiczną AND dla każdej ze skonfigurowanych właściwości. Po allowedApplications skonfigurowaniu i allowedPrincipals skonfigurowaniu żądania przychodzące musi spełniać oba wymagania, aby można je było zaakceptować.
allowedApplications Lista dozwolonych identyfikatorów klienta aplikacji ciągu reprezentujących zasób klienta wywołujący aplikację. Jeśli ta właściwość jest skonfigurowana jako tablica nonempty, akceptowane będą tylko tokeny uzyskane przez aplikację określoną na liście.

Te zasady oceniają appid oświadczenia lub azp tokenu przychodzącego, który musi być tokenem dostępu. Zobacz dokumentację Platforma tożsamości Microsoft oświadczeń.
allowedPrincipals Grupowanie testów, które określają, czy podmiot zabezpieczeń reprezentowany przez przychodzące żądanie może uzyskać dostęp do aplikacji. Satysfakcja wynika z allowedPrincipals tego, że wartość jest oparta na wartości logicznej OR względem skonfigurowanych właściwości.
identities (w obszarze allowedPrincipals) Lista dozwolonych identyfikatorów obiektów ciągów reprezentujących użytkowników lub aplikacje, które mają dostęp. Jeśli ta właściwość jest skonfigurowana jako tablica nonempty, wymaganie może być spełnione, allowedPrincipals jeśli użytkownik lub aplikacja reprezentowana przez żądanie jest określona na liście. Na liście tożsamości jest łącznie 500 znaków.

Te zasady oceniają oid oświadczenie tokenu przychodzącego. Zobacz dokumentację Platforma tożsamości Microsoft oświadczeń.

Ponadto niektóre testy można skonfigurować za pomocą ustawienia aplikacji, niezależnie od używanej wersji interfejsu API. Ustawienie WEBSITE_AUTH_AAD_ALLOWED_TENANTS aplikacji można skonfigurować z rozdzielaną przecinkami listą maksymalnie 10 identyfikatorów dzierżawy (np. "559a2f9c-c6f2-4d31-b8d6-5ad1a13f830,5693f64a-3ad5-4be7-b846-e9d1141bcebc"), aby wymagać, aby token przychodzący pochodzi z jednej z określonych dzierżaw, zgodnie tid z oświadczeniem. Ustawienie WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL aplikacji można skonfigurować na wartość "true" lub "1", aby wymagać tokenu przychodzącego oid w celu uwzględnienia oświadczenia. To ustawienie jest ignorowane i traktowane jako prawda, jeśli allowedPrincipals.identities zostało skonfigurowane (ponieważ oid oświadczenie jest sprawdzane względem tej udostępnionej listy tożsamości).

Żądania, które kończą się niepowodzeniem tych wbudowanych testów, otrzymują odpowiedź HTTP 403 Forbidden .

Konfigurowanie aplikacji klienckich w celu uzyskania dostępu do usługi App Service

W poprzednich sekcjach zarejestrowano usługę App Service lub funkcję platformy Azure w celu uwierzytelnienia użytkowników. W tej sekcji wyjaśniono, jak zarejestrować klientów natywnych lub aplikacji demona w identyfikatorze Entra firmy Microsoft, aby mogli żądać dostępu do interfejsów API uwidocznionych przez usługę App Service w imieniu użytkowników lub siebie, takich jak architektura N-warstwowa. Wykonanie czynności opisanych w tej sekcji nie jest wymagane, jeśli chcesz uwierzytelnić użytkowników.

Natywna aplikacja kliencka

Możesz zarejestrować klientów natywnych, aby zażądać dostępu do interfejsów API aplikacji usługi App Service w imieniu zalogowanego użytkownika.

  1. W menu portalu wybierz pozycję Microsoft Entra ID.

  2. W obszarze nawigacji po lewej stronie wybierz pozycję Rejestracje aplikacji> Nowa rejestracja.

  3. Na stronie Rejestrowanie aplikacji wprowadź nazwę rejestracji aplikacji.

  4. W polu Identyfikator URI przekierowania wybierz pozycję Klient publiczny (mobilny i klasyczny) i wpisz adres URL <app-url>/.auth/login/aad/callback. Na przykład https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Wybierz pozycję Zarejestruj.

  6. Po utworzeniu rejestracji aplikacji skopiuj wartość identyfikatora aplikacji (klienta).

    Uwaga

    W przypadku aplikacji ze sklepu Microsoft Store użyj identyfikatora SID pakietu jako identyfikatora URI.

  7. W obszarze nawigacji po lewej stronie wybierz pozycję Uprawnienia>interfejsu API Dodaj uprawnienie>Moje interfejsy API.

  8. Wybierz rejestrację aplikacji utworzoną wcześniej dla aplikacji usługi App Service. Jeśli rejestracja aplikacji nie jest widoczna, upewnij się, że dodano zakres user_impersonation w temacie Tworzenie rejestracji aplikacji w usłudze Microsoft Entra ID dla aplikacji usługi App Service.

  9. W obszarze Uprawnienia delegowane wybierz pozycję user_impersonation, a następnie wybierz pozycję Dodaj uprawnienia.

Teraz skonfigurowano natywną aplikację kliencką, która może żądać dostępu do aplikacji usługi App Service w imieniu użytkownika.

Aplikacja kliencka demona (wywołania typu service-to-service)

W architekturze N-warstwowej aplikacja kliencka może uzyskać token w celu wywołania aplikacji App Service lub funkcji w imieniu samej aplikacji klienckiej (nie w imieniu użytkownika). Ten scenariusz jest przydatny w przypadku aplikacji demonów nieinterakcyjnych, które wykonują zadania bez zalogowanego użytkownika. Używa ona standardowego przyznawania poświadczeń klienta OAuth 2.0.

  1. W menu portalu wybierz pozycję Microsoft Entra ID.
  2. W obszarze nawigacji po lewej stronie wybierz pozycję Rejestracje aplikacji> Nowa rejestracja.
  3. Na stronie Rejestrowanie aplikacji wprowadź nazwę rejestracji aplikacji.
  4. W przypadku aplikacji demona nie potrzebujesz identyfikatora URI przekierowania, aby zachować ten pusty identyfikator.
  5. Wybierz pozycję Zarejestruj.
  6. Po utworzeniu rejestracji aplikacji skopiuj wartość identyfikatora aplikacji (klienta).
  7. W obszarze nawigacji po lewej stronie wybierz pozycję Certyfikaty i wpisy tajne Klienta Wpisy>tajne>Nowego klienta.
  8. Wprowadź opis i wygaśnięcie, a następnie wybierz pozycję Dodaj.
  9. W polu Wartość skopiuj wartość wpisu tajnego klienta. Po przejściu z tej strony nie będzie ona ponownie wyświetlana.

Teraz możesz zażądać tokenu dostępu przy użyciu identyfikatora klienta i klucza tajnego klienta, ustawiając resource parametr na identyfikator URI identyfikatora aplikacji docelowej. Wynikowy token dostępu można następnie przedstawić aplikacji docelowej przy użyciu standardowego nagłówka autoryzacji OAuth 2.0, a uwierzytelnianie usługi App Service zweryfikuje i użyje tokenu tak jak zwykle, aby wskazać, że obiekt wywołujący (w tym przypadku aplikacja, a nie użytkownik) jest uwierzytelniony.

Obecnie pozwala to dowolnej aplikacji klienckiej w dzierżawie firmy Microsoft Entra zażądać tokenu dostępu i uwierzytelnić się w aplikacji docelowej. Jeśli chcesz również wymusić autoryzację , aby zezwolić tylko na niektóre aplikacje klienckie, musisz wykonać dodatkową konfigurację.

  1. Zdefiniuj rolę aplikacji w manifeście rejestracji aplikacji reprezentującej aplikację usługi App Service lub funkcję, którą chcesz chronić.
  2. W rejestracji aplikacji reprezentującej klienta, który musi być autoryzowany, wybierz pozycję Uprawnienia>interfejsu API Dodaj uprawnienie>Moje interfejsy API.
  3. Wybierz utworzoną wcześniej rejestrację aplikacji. Jeśli rejestracja aplikacji nie jest widoczna, upewnij się, że dodano rolę aplikacji.
  4. W obszarze Uprawnienia aplikacji wybierz utworzoną wcześniej rolę aplikacji, a następnie wybierz pozycję Dodaj uprawnienia.
  5. Upewnij się, że wybierz pozycję Udziel zgody administratora, aby autoryzować aplikację kliencą, aby zażądać uprawnień.
  6. Podobnie jak w poprzednim scenariuszu (przed dodaniem wszystkich ról), można teraz zażądać tokenu dostępu dla tego samego obiektu docelowego resource, a token dostępu będzie zawierać roles oświadczenie zawierające role aplikacji, które zostały autoryzowane dla aplikacji klienckiej.
  7. W docelowym kodzie aplikacji App Service lub Funkcji można teraz sprawdzić, czy oczekiwane role znajdują się w tokenie (nie jest to wykonywane przez uwierzytelnianie usługi App Service). Aby uzyskać więcej informacji, zobacz Uzyskiwanie dostępu do oświadczeń użytkowników.

Teraz skonfigurowano aplikację kliencką demona, która może uzyskiwać dostęp do aplikacji usługi App Service przy użyciu własnej tożsamości.

Najlepsze rozwiązania

Niezależnie od konfiguracji używanej do konfigurowania uwierzytelniania, następujące najlepsze rozwiązania zapewnią bezpieczeństwo dzierżawy i aplikacji:

  • Skonfiguruj każdą aplikację usługi App Service przy użyciu własnej rejestracji aplikacji w usłudze Microsoft Entra ID.
  • Nadaj każdej aplikacji usługi App Service 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ą.

Migrowanie do programu Microsoft Graph

Niektóre starsze aplikacje mogły być również skonfigurowane z zależnością od przestarzałego programu Azure AD Graph, który jest zaplanowany na pełne wycofanie. Na przykład kod aplikacji mógł wywołać usługę Azure AD Graph, aby sprawdzić członkostwo w grupie w ramach filtru autoryzacji w potoku oprogramowania pośredniczącego. Aplikacje powinny przejść do programu Microsoft Graph , postępując zgodnie ze wskazówkami dostarczonymi przez firmę Microsoft Entra ID w ramach procesu wycofywania usługi Azure AD Graph. W poniższych instrukcjach może być konieczne wprowadzenie pewnych zmian w konfiguracji uwierzytelniania usługi App Service. Po dodaniu uprawnień programu Microsoft Graph do rejestracji aplikacji możesz:

  1. Zaktualizuj adres URL wystawcy, aby uwzględnić sufiks "/v2.0", jeśli jeszcze tego nie zrobiono.

  2. Usuń żądania uprawnień usługi Azure AD Graph z konfiguracji logowania. Właściwości do zmiany zależą od używanej wersji interfejsu API zarządzania:

    • Jeśli używasz interfejsu API w wersji 1 (/authsettings), będzie to znajdować się w tablicy additionalLoginParams .
    • Jeśli używasz interfejsu API w wersji 2 (/authsettingsV2), będzie to znajdować się w tablicy loginParameters .

    Należy usunąć dowolne odwołanie do "https://graph.windows.net", na przykład. Obejmuje resource to parametr (który nie jest obsługiwany przez punkt końcowy "/v2.0") lub zakresy, których konkretnie żądasz z usługi Azure AD Graph.

    Należy również zaktualizować konfigurację, aby zażądać nowych uprawnień programu Microsoft Graph skonfigurowanych na potrzeby rejestracji aplikacji. Aby uprościć tę konfigurację w wielu przypadkach, możesz użyć zakresu domyślnego. W tym celu dodaj nowy parametr scope=openid profile email https://graph.microsoft.com/.defaultlogowania .

Dzięki tym zmianom, gdy uwierzytelnianie usługi App Service próbuje się zalogować, nie będzie już żądać uprawnień do programu Azure AD Graph, a zamiast tego otrzyma token dla programu Microsoft Graph. Każde użycie tego tokenu z kodu aplikacji również musi zostać zaktualizowane zgodnie ze wskazówkami podanymi przez identyfikator Firmy Microsoft Entra.

Następne kroki