Autoryzowanie aplikacji, zasobów i obciążeń przy użyciu identyfikatora Entra firmy Microsoft

W tym artykule omówiono autoryzację, gdy dana osoba wchodzi w interakcję z aplikacją i kieruje aplikację, gdy interfejsy programowania aplikacji (API) działają dla użytkownika. Omówiono również, gdy aplikacje lub usługi działają niezależnie. Jest to czwarty z serii artykułów na temat tego, jak niezależni deweloperzy oprogramowania (ISV) mogą tworzyć i optymalizować swoje aplikacje dla identyfikatora Entra firmy Microsoft. W tej serii możesz dowiedzieć się więcej o następujących tematach:

Autoryzacja w aplikacjach

W tej sekcji omówiono scenariusze, w których dana osoba wchodzi w interakcję z aplikacją i kieruje nią. W sekcji Autoryzacja w zasobach (API) opisano sposób, w jaki interfejsy API wykonują autoryzację, gdy użytkownik potrzebuje autoryzacji w celu uzyskania dostępu do zasobu, ale identyfikator Entra firmy Microsoft nie wykonuje ostatecznej autoryzacji. Sekcja Autoryzacja w obciążeniach obejmuje scenariusze, w których aplikacje lub usługi działają niezależnie.

Aplikacje wymagają następujących autoryzacji, gdy muszą uzyskiwać dostęp do zasobów dla użytkownika.

  • Aplikacja musi mieć autoryzację dostępu do określonych operacji w określonych zasobach dla bieżącego użytkownika.
  • Użytkownik musi mieć autoryzację dostępu do zasobu zgodnie z bieżącymi warunkami.
  • Użytkownik musi mieć autoryzację dostępu do zasobu.

Proces autoryzacji rozpoczyna się od aplikacji, która używa protokołu OAuth 2.0 do żądania tokenu dostępu z identyfikatora Entra firmy Microsoft w celu uzyskania dostępu do określonych operacji w ramach określonego zasobu dla użytkownika. W przypadku dostępu delegowanego aplikacja działa jako pełnomocnik użytkownika.

Dla deweloperów zasobem może być interfejs programistyczny, taki jak Microsoft Graph, Azure Storage lub ich własny interfejs programistyczny. Jednak większość interfejsów API ma różne operacje, takie jak odczytywanie i zapisywanie. Gdy aplikacja odczytuje tylko z interfejsu API, aplikacja powinna mieć autoryzację tylko do odczytu operacji. Takie podejście chroni aplikację przed naruszeniem zabezpieczeń i użyciem w celu uzyskania większego dostępu niż zamierzony przez dewelopera. Deweloper przestrzega zasady najniższych uprawnień, gdy aplikacja autoryzuje tylko te operacje, których wymaga.

Aby wyznaczyć określone operacje w określonym interfejsie API wymaganym przez aplikację, deweloperzy używają parametru zakresu żądania OAuth 2.0. Projektant interfejsu API publikuje zakresy, których aplikacja może zażądać w ramach rejestracji aplikacji interfejsu API. Na przykład zakresy usługa Power BI firmy Microsoft obejmują następujące elementy.

zakres usługa Power BI Operacje
https://analysis.windows.net/powerbi/api/Capacity.Read.All Aplikacja może wyświetlać wszystkie pojemności usługi Power BI Premium i Power BI Embedded, do których zalogowany użytkownik ma dostęp.
https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All Aplikacja może wyświetlać i edytować wszystkie pojemności usługi Power BI Premium i Power BI Embedded, do których zalogowany użytkownik ma dostęp.

Jeśli aplikacja odczytuje tylko pojemności, ona żąda https://analysis.windows.net/powerbi/api/Capacity.Read.All zakresu. Jeśli aplikacja edytuje pojemność, aplikacja żąda https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All zakresu.

Zakres zawiera tożsamość interfejsu API i tożsamość operacji. https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All W zakresie jest interfejs API https://analysis.windows.net/powerbi/api. Operacja to Capacity.ReadWrite.All. Biorąc pod uwagę szeroki zasięg i popularność Microsoft Graph API, deweloperzy mogą żądać zakresów dla Microsoft Graph bez składnika API zakresu. Na przykład, Microsoft Graph definiuje zakres https://graph.microsoft.com/Files.Read, o który aplikacje mogą wnioskować z Files.Read, zamiast używać pełnej nazwy zakresu.

Aby ukończyć pierwszą autoryzację, aplikacja musi mieć autoryzację dostępu do określonych operacji w ramach określonych zasobów dla bieżącego użytkownika. Identyfikator Entra firmy Microsoft musi najpierw uwierzytelnić bieżącego użytkownika. Logowanie jednokrotne (SSO) może spełniać to uwierzytelnianie lub może wymagać nowej interakcji użytkownika.

Po tym jak Microsoft Entra ID określi użytkownika, sprawdza, czy użytkownik autoryzował aplikację do żądanego zakresu. Ten proces jest nazywany udzielaniem zgody. Jeśli użytkownik udzielił zgody, proces autoryzacji może kontynuować. Zgoda administratora umożliwia administratorom wyrażanie zgody dla siebie i całej organizacji. Microsoft Entra ID sprawdza, czy aplikacja ma zgodę administratora dla zakresu. Jeśli zostanie udzielona, proces autoryzacji będzie kontynuowany.

Podczas projektowania zakresu projektant interfejsu API może wyznaczyć zakresy, dla których tylko administrator może wyrazić zgodę. Zakresy wymagające zgody administratora obejmują operacje, które projektant interfejsu API uznaje za bardziej wrażliwe, potężne lub mające szeroki wpływ, więc użytkownik niebędący administratorem nie powinien mieć uprawnień do przyznania ich aplikacji.

Chociaż projektanci interfejsów API mają pierwsze słowo w kwestii tego, które z ich zakresów wymagają zgody administratora, nie mają ostatecznej decyzji. Gdy projektant interfejsu API wyznaczy, że zakres wymaga zgody administratora, zakres zawsze wymaga zgody administratora. W przypadku zakresów, których projektant API nie określa jako wymagające zgody administratora, administrator dzierżawy może wymagać zgody administratora lub zgoda krokowa uzależniona od ryzyka może określić wymaganie zgody administratora. Deweloperzy nie mogą przewidzieć, czy żądanie tokenu wymaga zgody administratora. Jednak to ograniczenie nie ma wpływu na wymagany kod. Odmowa zgody jest tylko jednym z wielu powodów odmowy żądania tokenu. Aplikacje muszą zawsze odpowiednio obsługiwać brak otrzymania tokenu.

Jeśli użytkownik lub administrator nie udzielił zgody, użytkownik zobaczy monit o wyrażenie zgody, jak pokazano w poniższym przykładzie.

Zrzut ekranu przedstawiający monit o wyrażenie zgody użytkownika.

Monity dotyczące zgody administratora mogą pozwalać im wybrać pozycję Zgoda w imieniu organizacji w celu udzielenia zgody wszystkim użytkownikom w dzierżawcy, jak pokazano w poniższym przykładzie.

Zrzut ekranu przedstawiający monit o zgodę administratora.

Aplikacje kontrolują chronometraż monitów o zgodę użytkownika. Microsoft Entra ID obsługuje zgodę statyczną: gdy aplikacja używa zakresu .default, aplikacja żąda wszystkich uprawnień zadeklarowanych w rejestracji aplikacji. Ze statyczną zgodą aplikacja żąda z wyprzedzeniem wszystkich uprawnień, których kiedykolwiek potrzebuje.

Statyczna zgoda może zniechęcać użytkowników i administratorów do zatwierdzania żądania dostępu aplikacji. Najlepszym rozwiązaniem dla procesu żądania zgody jest żądanie wymaganych uprawnień dynamicznie dla funkcji punktu odniesienia w aplikacji podczas uruchamiania aplikacji i żądania większej liczby zakresów w razie potrzeby. Stopniowo żądaj większej liczby zakresów, gdy aplikacja wykonuje operacje wymagające tych zakresów. Takie podejście zapewnia użytkownikowi lepsze zrozumienie innych uprawnień, które są skorelowane z chronometrażem funkcjonalności. Dla każdego tokenu dostępu do interfejsu API, Microsoft Entra ID zawiera wszystkie zakresy wcześniej przyznane aplikacji, a nie tylko zakresy określone w żądaniu.

Na przykład aplikacja może zażądać https://graph.microsoft.com/user.read zalogowania użytkownika i uzyskania dostępu do profilu użytkownika po uruchomieniu aplikacji. Później użytkownik wybiera pozycję Zapisz w usłudze OneDrive , a aplikacja żąda https://graph.microsoft.com/files.readwrite zapisu pliku w usłudze OneDrive użytkownika. Ponieważ użytkownik widzi, dlaczego aplikacja prosi o zapisanie w usłudze OneDrive, użytkownik przyznaje uprawnienie, a aplikacja zapisuje plik w usłudze OneDrive użytkownika. Następnie użytkownik zamknie aplikację. Następnym razem, gdy aplikacja zostanie uruchomiona, zażąda żądania https://graph.microsoft.com/user.read. Microsoft Entra ID zwraca token dostępu z zakresami https://graph.microsoft.com/user.read i https://graph.microsoft.com/files.readwrite. Żądanie tokenu https://graph.microsoft.com/files.readwrite dla tego zakresu nie wymaga zgody, ponieważ użytkownik jej już udzielił. Buforowanie tokenów w bibliotekach Microsoft Authentication Libraries (MSAL) automatycznie obsługuje buforowanie tokenów na podstawie przyznanych uprawnień. W tym przykładzie, po ponownym uruchomieniu aplikacji, wywołania do MSAL w celu uzyskania tokenu o zakresie https://graph.microsoft.com/files.readwrite zwracają token zbuforowany z początkowego żądania aplikacji o zakresie https://graph.microsoft.com/user.read. Kolejne wywołanie identyfikatora Entra firmy Microsoft jest niepotrzebne.

Zgoda dynamiczna i przyrostowa nie wymaga zadeklarowanych uprawnień podczas rejestracji aplikacji. Zdecydowanie zalecamy jednak, aby aplikacje zadeklarowały wszelkie uprawnienia, których aplikacja może wymagać w rejestracji aplikacji w celu obsługi statycznej zgody. Administratorzy mogą udzielić zgody administratora w centrum administracyjnym firmy Microsoft Entra przy użyciu programu Microsoft Graph PowerShell lub interfejsu API programu Microsoft Graph.

Aby udzielić zgody administratora dla aplikacji, centrum administracyjne firmy Microsoft Entra używa statycznej zgody, żądając zgody z .default zakresem aplikacji. Administratorzy nie mogą udzielić zgody administratora w centrum administracyjnym firmy Microsoft dla aplikacji wymagających uprawnień, jeśli deweloperzy nie deklarują ich w rejestracji aplikacji.

Klienci usługi Microsoft Entra ID mogą używać zasad dostępu warunkowego do ochrony zasobów (interfejsów API) i aplikacji opartych na przeglądarce. Domyślnie administratorzy nie mogą stosować zasad dostępu warunkowego do uwierzytelniania aplikacji natywnych. Administratorzy dzierżawcy mogą stosować wszystkie zasoby (dawniej "Wszystkie aplikacje w chmurze") lub używać niestandardowych atrybutów zabezpieczeń do obsługi aplikacji natywnych za pomocą zasad dostępu warunkowego. Nawet w przypadku, gdy jest to celowe, wymuszanie zasad nie obejmuje niektórych aplikacji , które uzyskują dostęp do programu Microsoft Graph lub usługi Azure AD Graph.

Aplikacje zwykle nie wymagają specjalnego kodu dla dostępu warunkowego, chyba że zostaną zastosowane następujące scenariusze.

  • Aplikacje, które wykonują przepływ realizujący działania w imieniu użytkownika
  • Aplikacje, które uzyskują dostęp do wielu usług lub zasobów
  • Aplikacje jednostronicowe korzystające z MSAL.js
  • Aplikacje internetowe wywołujące zasób

Jeśli aplikacja implementuje dowolny z tych scenariuszy, zapoznaj się ze wskazówkami dla deweloperów dotyczącymi dostępu warunkowego firmy Microsoft Entra.

Bezpłatne dzierżawy Microsoft Entra ID nie mogą korzystać z Dostępu Warunkowego (zobacz wymagania dotyczące licencjonowania). Instancja produkcyjna Twojej firmy może mieć wymagane licencje. Przed użyciem dzierżawy produkcyjnej do testowania należy ocenić te warunki. Istnieją wskazówki dotyczące tworzenia testowego dzierżawcy.

Domyślnie zasady dostępu warunkowego mają zastosowanie do aplikacji i zasobów, do których aplikacja uzyskuje dostęp na poziomie aplikacji. Administratorzy IT mogą stosować zasady na poziomie aplikacji do dowolnej aplikacji bez udziału deweloperów. Niektóre aplikacje i scenariusze wymagają większej szczegółowości. Na przykład aplikacja finansowa może wymagać uwierzytelniania wieloskładnikowego do typowego użycia. Jednak transakcja na określoną kwotę może wymagać zarządzanego urządzenia. Deweloperzy mogą umożliwić administratorom IT przypisanie krokowych zasad dostępu warunkowego do różnych obszarów aplikacji przez zaimplementowanie kontekstu uwierzytelniania dostępu warunkowego. Przewodnik dla deweloperów dotyczący kontekstu uwierzytelniania dostępu warunkowego jest dobrym rozwiązaniem dla tych funkcji.

Domyślnie identyfikator Entra firmy Microsoft wystawia tokeny dostępu, które są prawidłowe przez ustawiony czas. Aplikacje nigdy nie muszą zakładać długości okresu istnienia. Muszą użyć parametru expires_in zwróconego przez Microsoft Entra ID z tokenem dostępu. Biblioteka MSAL automatycznie obsługuje tę sytuację. W okresie istnienia tokenu dostępu użytkownik ma autoryzację dostępu do zasobu zgodnie z warunkami w momencie autoryzacji.

Opóźnienie między zmianą warunków a wymuszaniem zmian zasad może dotyczyć administratorów i użytkowników. Na przykład gdy użytkownik utraci urządzenie, administrator IT może odwołać sesje użytkownika. Jednak aplikacja na utraconym urządzeniu może nadal uzyskiwać dostęp do programu Microsoft Graph dla użytkownika do momentu wygaśnięcia tokenu. Ciągła ocena dostępu (CAE) firmy Microsoft może uniemożliwić dostęp po odwołaniu sesji użytkowników dla aplikacji, które przyjmują caE. Jeśli aplikacja wywołuje program Microsoft Graph co najmniej raz na godzinę, możesz wdrożyć usługę CAE. Sposób używania interfejsów API z obsługą Ciągłej Oceny Dostępu w aplikacjach zawiera szczegóły implementacji.

Jeśli nie możesz skompilować biblioteki MSAL, aplikacja musi użyć protokołu OAuth 2.0, aby zażądać tokenów dostępu z identyfikatora Entra firmy Microsoft. Platforma tożsamości Microsoft i przepływ kodu autoryzacji OAuth 2.0 zawiera szczegóły implementacji przepływów obsługiwanych przez Microsoft Entra ID.

Jeśli tworzysz aplikacje urządzeń przenośnych, zapoznaj się z artykułem Obsługa logowania jednokrotnego i zasad ochrony aplikacji w aplikacjach mobilnych. Dowiedz się, jak obsługiwać pozyskiwanie tokenów, zarządzanie aplikacjami mobilnymi (MAM) usługi Intune i zasady ochrony aplikacji.

Autoryzacja w zasobach (interfejsy API)

Sekcja Autoryzacja w aplikacjach wprowadziła trzy wymagane autoryzacje, gdy aplikacje muszą uzyskiwać dostęp do zasobów dla użytkownika, ale obejmowały tylko pierwsze dwa. Użytkownik musi mieć autoryzację dostępu do zasobu, ale identyfikator Entra firmy Microsoft nie wykonuje ostatecznej autoryzacji. Zasób (API) wykonuje autoryzację.

Interfejsy API muszą wymuszać dwie autoryzacje podczas działania w imieniu użytkownika:

  • Interfejsy API muszą umożliwić aplikacji uzyskanie autoryzacji, aby wywołać je. Sprawdź, czy oświadczenie tokenu scp dostępu (zakres) zawiera wymagany zakres.
  • Interfejsy API muszą autoryzować użytkownika w celu uzyskania dostępu do określonego zasobu. Oświadczenia oid (identyfikator obiektu) i sub (podmiot) w tokenie reprezentują tożsamość użytkownika.

Zalecamy żądania oid i sub dotyczące autoryzacji.

Microsoft Entra ID implementuje oświadczenie parowe sub , dlatego sub oświadczenie jest unikatowym identyfikatorem użytkownika dla żądanej aplikacji. Ten sam użytkownik korzystający z innej aplikacji ma inne sub oświadczenie. Deklaracja oid jest stała dla użytkownika przez wszystkie aplikacje.

Aplikacje udostępniają wymagany token dostępu do interfejsów API chronionych przez Microsoft Entra ID w nagłówku autoryzacyjnym żądania jako token uwierzytelniający. Interfejsy API muszą w pełni zweryfikować odebrany token, ponieważ token nie pochodzi bezpośrednio z identyfikatora Entra firmy Microsoft. Traktuj aplikację jako niezaufaną aż do czasu weryfikacji tokenu. Referencje dotyczące tokenu dostępu i walidacji oświadczeń zawierają szczegółowe informacje na temat weryfikowania tokenów dostępu Microsoft Entra ID.

Identyfikator Entra firmy Microsoft publikuje klucze publiczne używane przez interfejsy API do sprawdzania poprawności podpisu tokenu. Te klucze są okresowo rotowane i zawsze, gdy sytuacja wymaga rotacji kluczy publicznych. Aplikacja nigdy nie powinna zakładać ustalonego harmonogramu zmiany kluczy publicznych. Przerzucanie klucza podpisywania w Platforma tożsamości Microsoft wyjaśnia, jak prawidłowo obsługiwać przerzucanie klucza publicznego.

Zalecamy używanie dobrze utrzymywanej biblioteki do przeprowadzania weryfikacji tokenu. Jeśli tworzysz aplikację internetową lub interfejs API w ASP.NET lub ASP.NET Core, użyj polecenia Microsoft.Identity.Web do obsługi weryfikacji tokenu. W artykule instrukcje dotyczącym chronionego interfejsu API wyjaśniono, jak użyć Microsoft.Identity.Web do ochrony interfejsu API.

API czasami potrzebuje wywołać inne API. Gdy aplikacja działa dla użytkownika, interfejs API otrzymuje delegowany token dostępu, który zawiera tożsamość bieżącego użytkownika. Ważne jest, aby interfejs API ufał tylko zweryfikowanemu tokenowi z Microsoft Entra ID w celu określenia tożsamości bieżącego użytkownika. Takie podejście uniemożliwia naruszenie zabezpieczeń aplikacji, dzięki czemu użytkownicy personifikują innych użytkowników i uzyskują dostęp do zasobów dla innego użytkownika. W przypadku tej samej ochrony, gdy jeden interfejs API wywołuje inny interfejs API, użyj przepływu On Behalf Of OAuth, aby uzyskać token dostępu w celu wywołania interfejsu API dla użytkownika, dla którego wywołano interfejs API. Tworzenie internetowego API, które wywołuje inne API, zawiera kroki dotyczące wywoływania innych API dla bieżącego użytkownika aplikacji.

Oprócz dostępu delegowanego, interfejsy API mogą wymagać wspierania aplikacji i działać niezależnie bez aktywnych użytkowników. Identyfikator Entra firmy Microsoft odnosi się do tych aplikacji jako obciążeń. Aby wymusić autoryzację obciążenia roboczego, interfejsy API nie używają deklaracji scp (zakresu). Zamiast tego interfejsy API używają klauzuli roles, aby sprawdzić, czy obciążenie ma wymaganą zgodę. Interfejsy API są odpowiedzialne za zapewnienie, że zadanie ma uprawnienia do dostępu do zasobu.

Autoryzacja w obciążeniach roboczych

Obciążenia to aplikacje, które działają niezależnie i nie mają bieżącego użytkownika. Podobnie jak dostęp delegowany omówiony w sekcji Autoryzacja w aplikacjach, dostęp tylko do aplikacji wymaga kilku autoryzacji:

  • Aplikacja musi mieć autoryzację dostępu do określonych operacji w określonych zasobach.
  • Aplikacja musi mieć autoryzację dostępu do zasobu zgodnie z bieżącymi warunkami.
  • Aplikacja musi mieć autoryzację dostępu do zasobu.

Proces rozpoczyna się od zadania żądającego tokenu dostępu z zakresem .default (na przykład https://graph.microsoft.com/.default). W przeciwieństwie do dostępu delegowanego (aplikacje mogą dynamicznie i przyrostowo żądać uprawnień), procesy muszą zawsze używać statycznej zgody i .default zakresu.

Projektanci interfejsu API tworzą uprawnienia aplikacji dla swojego interfejsu API, dodając role do rejestracji aplikacji w interfejsie API. Te role mają dozwolony typ składowy aplikacji, co umożliwia przypisanie roli do obciążeń. Przypisz role do obciążeń w centrum administracyjnym firmy Microsoft Entra lub za pomocą programu Microsoft Graph. W centrum administracyjnym firmy Microsoft Entra zgoda administratora dla przypisanych ról jest niezbędna przed uruchomieniem obciążenia.

Domyślnie zezwolenie aplikacji upoważnia obciążenia robocze do uzyskania dostępu do wszystkich wystąpień zasobu. Na przykładhttps://graph.microsoft.com/user.read.all autoryzuje obciążenie w celu uzyskania dostępu do pełnego profilu użytkownika każdego użytkownika w dzierżawie. Administratorzy IT często niechętnie udzielają tych szerokich uprawnień.

W przypadku obciążeń, które uzyskują dostęp do programu Microsoft Graph, użyj następujących metod, aby ograniczyć uprawnienia aplikacji:

  • Usługa Microsoft Teams implementuje zgodę specyficzną dla zasobów.
  • Usługa Exchange Online implementuje zasady dostępu do aplikacji.
  • Program SharePoint implementuje Sites.Selected zakres zgody specyficznej dla zasobów.

W przeciwieństwie do aplikacji z użytkownikami zadania uwierzytelniają się w usłudze Microsoft Entra ID.

W przypadku obciążeń uruchamianych na platformie Microsoft Azure najlepszą metodą uwierzytelniania obciążenia jest tożsamość zarządzana dla zasobów platformy Azure. Funkcja zarządzanych tożsamości eliminuje konieczność zarządzania poświadczeniami dla zadań obliczeniowych. Brak dostępnych poświadczeń. Identyfikator Entra firmy Microsoft w pełni zarządza poświadczeniami. Bez poświadczeń do zarządzania, żadne poświadczenia nie są zagrożone naruszeniem.

Dzięki zwiększonym zabezpieczeniom, zarządzane tożsamości również zwiększają odporność. Tożsamości zarządzane używają długowiecznych tokenów dostępu oraz informacji z Microsoft Entra ID, aby uzyskiwać nowe tokeny przed ich wygaśnięciem. Zarządzane tożsamości używają regionalnych punktów końcowych, które pomagają zapobiegać awariom usług poza regionem poprzez konsolidację zależności usług. Regionalne punkty końcowe pomagają zachować ruch w obszarze geograficznym. Jeśli na przykład zasób platformy Azure znajduje się w regionie WestUS2, cały ruch pozostaje w regionie WestUS2.

Jeśli obciążenie nie jest uruchomione na platformie Microsoft Azure, obciążenie musi uwierzytelniać się przy użyciu przepływu poświadczeń klienta OAuth 2.0.

Identyfikator Entra firmy Microsoft obsługuje następujące typy poświadczeń klienta:

  • Certyfikat. Obciążenia dowodzą, że mają klucz prywatny, podpisując asercję przy użyciu klucza prywatnego. Klucz prywatny nie jest przesyłany do identyfikatora Entra firmy Microsoft. Wysyłana jest tylko asercja. Zalecamy certyfikaty zamiast wpisów tajnych klienta, ponieważ są one bezpieczniejsze i często lepiej zarządzane.
  • Poświadczenie federacyjne. Łączność tożsamości dla obciążenia umożliwia obciążeniom, które nie są uruchomione na platformie Microsoft Azure, używanie tożsamości z innego dostawcy tożsamości, GitHub Actions lub klastra Kubernetes. Obciążenia żądają tokenów w taki sam sposób, jak w przypadku poświadczeń federacyjnych, co w przypadku poświadczeń certyfikatu. Różnica polega na tym, że asercja, podpisany sieciowy token JSON, pochodzi od dostawcy tożsamości federacyjnej.
  • Tajny klucz klienta. Czasami nazywany hasłem aplikacji, tajny klucz klienta jest wartością ciągu, za pomocą której obciążenie może się identyfikować. Wartość tajemnicy w formie tekstowej jest wysyłana z obciążenia roboczego do Microsoft Entra ID w żądaniu POST w celu uzyskania tokenu. Tajne dane klienta są mniej bezpieczne niż certyfikaty lub federacja tożsamości aplikacji. Jeśli obciążenie używa tajnych danych, postępuj zgodnie z tymi najlepszymi praktykami zarządzania tajnymi danymi.

Oprócz Microsoft Entra ID, rodzina produktów Microsoft Entra obejmuje Microsoft Entra Workload ID. Identyfikator obciążeń Microsoft Entra oferuje następujące funkcje w wersji Premium w celu poprawy bezpieczeństwa obciążeń.

Obciążenia mogą obsługiwać ocenę ciągłego dostępu (CAE), jeśli wywołają program Microsoft Graph co najmniej raz na godzinę. Aby obsługiwać CAE, obciążenie musi być aplikacją przeznaczoną dla jednego dzierżawcy i zarejestrowaną w dzierżawie, w której uzyskuje dostęp do Microsoft Graph. Jeśli obciążenie spełnia te wymagania, zapoznaj się z tym przykładem, aby zapoznać się z krokami implementacji.

Następne kroki

  • Ostatnia aktualizacja o