Zagadnienia dotyczące wysokiej dostępności w MSAL.NET

Aby zapoznać się z przepływem poświadczeń klienta, zobacz najpierw dokumentację przepływów poświadczeń klienta .

Użyj interfejsu API wyższego poziomu

MSAL to interfejs API niższego poziomu. Jeśli piszesz nową aplikację, rozważ użycie wyższego poziomuMicrosoft.Identitity.Web, który zapewnia integrację z ASP.NET Core i ASP.NET Classic.

Użyj najnowszej wersji MSAL

Użyj najnowszej biblioteki MSAL, aby uzyskać poprawki błędów i ulepszenia wydajności. Są przestrzegane reguły semantycznego przechowywania wersji.

Warto również sprawdzić, czy nie należy użyć Microsoft Identity Web, biblioteki wyższego poziomu abstrakcji dla aplikacji internetowych i internetowych interfejsów API, która realizuje za Ciebie wiele zadań opisanych poniżej. Zobacz Wybieranie wersji MSAL.NET, która proponuje drzewo decyzyjne, aby wybrać najlepsze rozwiązanie w zależności od platformy i ograniczeń.

Użyj pamięci podręcznej tokenów

Domyślne zachowanie: MSAL buforuje tokeny w pamięci. Każda instancja ConfidentialClientApplication ma własną wewnętrzną pamięć podręczną tokenów. Pamięć podręczna przechowywana w pamięci może zostać utracona, na przykład jeśli instancja obiektu zostanie zwolniona lub cała aplikacja zostanie zatrzymana.

Zalecenie: Wszystkie aplikacje powinny utrwalać swoje pamięci podręczne tokenów. Aplikacje Web i interfejsy API w sieci Web powinny używać pamięci podręcznej tokenów L1/L2, gdzie L2 jest magazynem rozproszonym, takim jak Redis, aby obsłużyć skalowanie. Aplikacje komputerowe powinny używać właściwej strategii serializacji pamięci podręcznej tokenów.

Domyślne zachowanie: Biblioteka MSAL obsługuje pomocniczą pamięć podręczną tokenów biblioteki ADAL na potrzeby scenariuszy migracji między biblioteką ADAL i biblioteką MSAL. Operacje na pamięci podręcznej ADAL są bardzo powolne. Zalecenie: Wyłącz pamięć podręczną biblioteki ADAL, jeśli nie interesuje Cię migracja z biblioteki ADAL. Spowoduje to dużą poprawę wydajności — zobacz pomiary wydajności tutaj.

Dodaj WithLegacyCacheCompatibility(false) podczas tworzenia aplikacji, aby wyłączyć buforowanie biblioteki ADAL.

Dodaj monitorowanie operacji MSAL

Biblioteka MSAL udostępnia ważne metryki jako część obiektu AuthenticationResult.AuthenticationResultMetadata:

Logging

Nasłuchuj komunikatów poziomu Warning i Error pochodzących z dzienników MSAL. Mogą to być ciche błędy lub zdecydowane zalecenia dotyczące użycia innej konfiguracji. Nie zaleca się włączania rejestrowania Verbose w środowisku produkcyjnym, ponieważ generuje ono dużo komunikatów i wpływa na wydajność.

Szczegółowe informacje na temat rejestrowania można znaleźć w przewodniku Rejestrowanie w MSAL.NET.

Zasady ponawiania

Zachowanie domyślne: MSAL ponowi nieudane żądania 5xx jeden raz.

Zalecenie:

• Zapoznaj się z naszą dokumentacją zasad ponawiania, aby utworzyć zasady ponawiania za pomocą Polly

Jeden poufny klient na sesję

Zaleca się używać nowego ConfidentialClientApplication dla każdej sesji i stosować tę samą serializację — jedna pamięć podręczna tokenów na sesję. Zwiększa to również bezpieczeństwo. Oficjalne przykłady pokazują, jak to zrobić. Należy skonfigurować buforowanie tokenów , aby działało prawidłowo.

HttpClient

Zachowanie domyślne: obiekt HttpClient utworzony przez bibliotekę MSAL nie skaluje się dobrze w przypadku witryn internetowych i internetowych interfejsów API, w których zalecamy utworzenie obiektu ClientApplication dla każdej sesji użytkownika.

Zalecenie: Podaj własną skalowalną właściwość HttpClientFactory. W środowisku .NET Core zalecamy wstrzykiwanie elementu System.Net.Http.IHttpClientFactory. Opisano to bardziej szczegółowo w przewodniku Zapewnianie własnego klienta HttpClient, obsługi serwerów proxy HTTP i dostosowywaniu nagłówków agenta użytkownika oraz w dokumentacji .NET

Proaktywne odnawianie tokenu

Goal

Zwiększ dostępność aplikacji, wydając dłuższe tokeny dostępu i upewnij się, że są odświeżane wcześniej niż data wygaśnięcia.

Stan quo

Domyślnie Microsoft Entra ID wystawia tokeny dostępu z upływem 1 godziny. Jeśli wystąpi awaria usługi Microsoft Entra w momencie, gdy token będzie wymagał odświeżenia, biblioteka MSAL zakończy działanie niepowodzeniem. Awaria jest propagowana do aplikacji wywołującej i ma wpływ na dostępność.

Proces

Aby poprawić dostępność, MSAL stara się zapewnić, aby aplikacja zawsze miała aktualne, niewygasłe tokeny. Awarie usługi Microsoft Entra rzadko trwają dłużej niż kilka godzin, więc jeśli biblioteka MSAL może zagwarantować, że token zawsze zachowuje ważność przez co najmniej kilka kolejnych godzin, aplikacja nie odczuje skutków awarii usługi Microsoft Entra.

Aby uzyskać tokeny długoterminowe, należy skonfigurować dzierżawę (uwaga: wewnętrzne dzierżawy firmy Microsoft są już skonfigurowane). W przypadku client_credentials (usługa 2) wystarczy. W przypadku poświadczeń użytkownika należy również skonfigurować funkcję CAE — /azure/active-directory/conditional-access/concept-continuous-access-evaluation.

Gdy Microsoft Entra ID zwraca token o długim okresie ważności, zawiera pole refresh_in. Zazwyczaj ustawia się go na połowę okresu ważności tokenu dostępu.

Uwaga: W MSAL 4.37.0 i nowszych wersjach możesz sprawdzić tę wartość, sprawdzając element AuthenticationResult.AuthenticationResultMetadata.RefreshOn.

Ponadto można skonfigurować okres istnienia tokenu przekraczający domyślną 1 godzinę, zgodnie z opisem w temacie Konfigurowanie okresów istnienia tokenu w Platforma tożsamości Microsoft (wersja zapoznawcza).

Za każdym razem, gdy wysyłasz żądania dotyczące tego samego tokenu, tj. za każdym razem, gdy biblioteka MSAL może obsłużyć token z jego pamięci podręcznej, biblioteka MSAL automatycznie sprawdzi refresh_in wartość. Jeśli token wygasł, biblioteka MSAL wyśle w tle żądanie tokenu do usługi Microsoft Entra ID, ale zwróci aplikacji istniejący, prawidłowy token. W mało prawdopodobnym przypadku niepowodzenia odświeżania w tle (np. z powodu awarii usługi Microsoft Entra) nie wpływa to na działanie aplikacji.

Rotacja certyfikatów

Certyfikaty dla poufnej aplikacji klienckiej muszą być obracane ze względów bezpieczeństwa (nie używaj wpisów tajnych w wersji prod!). Istnieje kilka sposobów obsługi rotacji certyfikatów w kolejności najbardziej preferowanej do najmniejszej:

1. Korzystanie z tożsamości zarządzanej

W przypadku tożsamości zarządzanej zaufanie jest ustanawiane za pośrednictwem hostowania aplikacji w Azure. Nie ma sekretów do utrzymania ani certyfikatów do odnowienia.

2. Używanie logiki obsługi certyfikatów Microsoft.Identity.Web

W aplikacjach internetowych i internetowych interfejsach API użyj Microsoft.Identity.Web, interfejsu API wyższego poziomu opartego na bibliotece MSAL. Obsługuje rotację certyfikatów, gdy certyfikat jest przechowywany w Azure Key Vault i obsługuje również przypadek tożsamości zarządzanej.

Dowiedz się więcej w przewodniku Certyfikaty w Microsoft.Identity.Web.

Jest to preferowane rozwiązanie dla usług wewnętrznych innych niż Microsoft przy użyciu ASP.NET Core.

3. (Tylko do użytku wewnętrznego firmy Microsoft) Polegaj na certyfikatach Subject Name/Issuer.

Ten mechanizm umożliwia Microsoft Entra ID identyfikowanie certyfikatu na podstawie sn/I zamiast odcisku palca (x5t). Jest to rozwiązanie tymczasowe; nie ma planów, aby udostępnić je aplikacjom spoza firmy Microsoft.

Jest to preferowane rozwiązanie dla Microsoft usług wewnętrznych, które nie mogą używać tożsamości zarządzanej.