Udostępnij przez


Zwiększanie odporności uwierzytelniania i autoryzacji w opracowywanych aplikacjach klienckich

Dowiedz się, jak tworzyć odporność w aplikacjach klienckich, które używają platformy tożsamości firmy Microsoft i identyfikatora Entra firmy Microsoft do logowania użytkowników, i wykonywać akcje w imieniu tych użytkowników.

Korzystanie z biblioteki Microsoft Authentication Library (MSAL)

Biblioteka Microsoft Authentication Library (MSAL) jest częścią platformy tożsamości firmy Microsoft. Biblioteka MSAL uzyskuje, zarządza, buforuje i odświeża tokeny; stosuje najlepsze praktyki zapewniające odporność. MSAL pomaga deweloperom tworzyć bezpieczne rozwiązania.

Więcej informacji:

Biblioteka MSAL buforuje tokeny i używa wzorca cichego pozyskiwania tokenu. MSAL serializuje pamięć podręczną tokenów w systemach operacyjnych, które natywnie dostarczają bezpieczne przechowywanie, takich jak platforma uniwersalna systemu Windows (UWP), iOS i Android. Dostosuj zachowanie serializacji podczas korzystania.

  • Microsoft.Identity.Web
  • MSAL.NET
  • Biblioteka MSAL dla języka Java
  • BIBLIOTEKA MSAL dla języka Python

Więcej informacji:

W przypadku korzystania z biblioteki MSAL obsługiwane jest buforowanie tokenów, odświeżanie i pozyskiwanie dyskretne. Użyj prostych wzorców, aby uzyskać tokeny na potrzeby uwierzytelniania. Obsługa wielu języków jest dostępna. Znajdź przykładowy kod w witrynie Przykłady kodu platformy tożsamości firmy Microsoft.

try
{
    result = await app.AcquireTokenSilent(scopes, account).ExecuteAsync();
}
catch(MsalUiRequiredException ex)
{
    result = await app.AcquireToken(scopes).WithClaims(ex.Claims).ExecuteAsync()
}

Biblioteka MSAL może odświeżać tokeny. Gdy platforma tożsamości firmy Microsoft wystawia długotrwały token, może wysyłać informacje do klienta w celu odświeżenia tokenu (refresh_in). Aplikacja działa, gdy stary token jest ważny, ale pozyskanie nowego tokenu trwa dłużej.

Wydania biblioteki MSAL

Zalecamy deweloperom utworzenie procesu korzystania z najnowszej wersji biblioteki MSAL, ponieważ uwierzytelnianie jest częścią zabezpieczeń aplikacji. Używaj tej praktyki w przypadku bibliotek będących w fazie rozwoju, aby zwiększyć odporność aplikacji.

Znajdź najnowszą wersję i uwagi do wydania:

Odporne wzorce obsługi tokenów

Jeśli nie używasz biblioteki MSAL, użyj odpornych wzorców na potrzeby obsługi tokenów. Biblioteka MSAL implementuje najlepsze rozwiązania.

Ogólnie rzecz biorąc, aplikacje korzystające z nowoczesnego uwierzytelniania wywołają punkt końcowy w celu pobrania tokenów uwierzytelniających użytkownika lub autoryzowania aplikacji do wywoływania chronionych interfejsów API. MSAL obsługuje uwierzytelnianie i implementuje wzorce w celu zwiększenia odporności. Jeśli nie używasz biblioteki MSAL, skorzystaj ze wskazówek w tej sekcji, aby uzyskać najlepsze rozwiązania. W przeciwnym razie biblioteka MSAL automatycznie implementuje najlepsze rozwiązania.

System uwierzytelniania kopii zapasowych Microsoft Entra ID zapewnia odporność aplikacjom korzystającym z obsługiwanych protokołów i przepływów. Aby uzyskać więcej informacji na temat wymagań aplikacji w celu skorzystania z uwierzytelniania kopii zapasowej, zobacz wymagania aplikacji dotyczące systemu uwierzytelniania kopii zapasowych.

Tokeny pamięci podręcznej

Upewnij się, że aplikacje dokładnie buforują tokeny z platformy tożsamości Microsoft. Po odebraniu przez aplikację tokenów odpowiedź HTTP z tokenami ma właściwość wskazującą expires_in czas trwania buforowania oraz czas ponownego użycia. Upewnij się, że aplikacja nie próbuje dekodować tokenu dostępu interfejsu API.

Diagram przedstawiający aplikację wywołującą platformę tożsamości firmy Microsoft za pośrednictwem pamięci podręcznej tokenów na urządzeniu z uruchomioną aplikacją.

Buforowane tokeny uniemożliwiają niepotrzebny ruch między aplikacją a platformą tożsamości firmy Microsoft. Ten scenariusz sprawia, że aplikacja jest mniej podatna na błędy pozyskiwania tokenów, zmniejszając liczbę wywołań pozyskiwania tokenów. Buforowane tokeny zwiększają wydajność aplikacji, ponieważ aplikacja blokuje uzyskiwanie tokenów rzadziej. Użytkownicy pozostają zalogowani do aplikacji na okres istnienia tokenu.

Serializowanie i utrwalanie tokenów

Upewnij się, że aplikacje bezpiecznie serializują pamięć podręczną tokenów, aby zachowały tokeny między wystąpieniami aplikacji. Ponowne używanie tokenów w okresie ich istnienia. Tokeny odświeżania i tokeny dostępu są wystawiane przez wiele godzin. W tym czasie użytkownicy mogą wielokrotnie uruchamiać aplikację. Po uruchomieniu aplikacji upewnij się, że szuka prawidłowego dostępu lub tokenu odświeżania. Zwiększa to odporność i wydajność aplikacji.

Więcej informacji:

Upewnij się, że trwały magazyn tokenów ma kontrolę dostępu i szyfrowanie w odniesieniu do tożsamości użytkownika lub procesu. W różnych systemach operacyjnych istnieją funkcje magazynu poświadczeń.

Uzyskiwanie tokenów w trybie dyskretnym

Uwierzytelnianie użytkownika lub pobieranie autoryzacji w celu wywołania interfejsu API wiąże się z wieloma krokami na platformie tożsamości firmy Microsoft. Na przykład użytkownicy logujący się po raz pierwszy wprowadzają poświadczenia i wykonują uwierzytelnianie wieloskładnikowe. Każdy krok ma wpływ na zasób, który udostępnia usługę. Najlepsze doświadczenie użytkownika z najmniejszymi zależnościami to bezgłośne uzyskiwanie tokenu.

Diagram usług platformy tożsamości firmy Microsoft, które ułatwiają ukończenie uwierzytelniania lub autoryzacji użytkownika.

Pozyskiwanie tokenu dyskretnego rozpoczyna się od prawidłowego tokenu z pamięci podręcznej tokenu aplikacji. Jeśli nie ma prawidłowego tokenu, aplikacja próbuje uzyskać token przy użyciu dostępnego tokenu odświeżania i punktu końcowego tokenu. Jeśli żadna z opcji nie jest dostępna, aplikacja uzyskuje token przy użyciu parametru prompt=none . Ta akcja używa punktu końcowego autoryzacji, ale dla użytkownika nie jest wyświetlany żaden interfejs graficzny. Jeśli to możliwe, platforma tożsamości firmy Microsoft udostępnia token aplikacji bez interakcji z użytkownikiem. Jeśli żadna metoda nie powoduje tokenu, użytkownik ręcznie ponownie uwierzytelnia.

Uwaga / Notatka

Ogólnie rzecz biorąc, upewnij się, że aplikacje nie używają monitów, takich jak "login" i "consent". Te monity wymuszają interakcję użytkownika, gdy nie jest wymagana żadna interakcja.

Obsługa kodu odpowiedzi

Skorzystaj z poniższych sekcji, aby dowiedzieć się więcej o kodach odpowiedzi.

Kod odpowiedzi HTTP 429

Istnieją odpowiedzi błędne wpływające na odporność. Jeśli aplikacja odbiera kod odpowiedzi HTTP 429, Zbyt wiele żądań, platforma tożsamości firmy Microsoft ogranicza żądania. Jeśli aplikacja wysyła zbyt wiele żądań, ogranicza ją, aby uniemożliwić aplikacji odbieranie tokenów. Nie zezwalaj aplikacji na próbę uzyskania tokenu, do czasu zakończenia okresu wskazanego w polu odpowiedzi Retry-After. Często odpowiedź 429 wskazuje, że aplikacja nie buforuje i nie poprawnie wykorzystuje tokenów. Sprawdź, jak tokeny są buforowane i ponownie używane w aplikacji.

Kod odpowiedzi HTTP 5x

Jeśli aplikacja otrzyma kod odpowiedzi HTTP 5x, aplikacja nie może wprowadzić szybkiej pętli ponawiania. Użyj tej samej obsługi dla odpowiedzi 429. Jeśli nie pojawi się nagłówek Retry-After, zaimplementuj retry z wykładniczym zwiększaniem odstępów, zaczynając od ponowienia co najmniej 5 sekund po odpowiedzi.

Po upłynięciu limitu czasu dla żądania, odradza się natychmiastowe ponawianie prób. Zaimplementuj wykładnicze ponawianie próby, przy czym pierwsza próba powinna nastąpić co najmniej 5 sekund po odpowiedzi.

Wiele aplikacji i interfejsów API wymaga autoryzowania informacji o użytkowniku. Dostępne metody mają zalety i wady.

Tokeny

Tokeny tożsamości (ID) i tokeny dostępu mają standardowe oświadczenia, które zawierają informacje. Jeśli potrzebne informacje są w tokenie, najbardziej wydajną techniką jest korzystanie z twierdzeń tokenu, ponieważ uniemożliwia to kolejne wywołanie sieciowe. Mniejsza liczba wywołań sieciowych równa się lepszej odporności.

Więcej informacji:

Uwaga / Notatka

Niektóre aplikacje odwołują się do punktu końcowego UserInfo w celu pobrania informacji dotyczących uwierzytelnionego użytkownika. Informacje w tokenie identyfikatora są nadzbiorem informacji z punktu końcowego UserInfo. Włącz aplikacjom korzystanie z tokenu ID zamiast wywoływania punktu końcowego UserInfo.

Rozszerz standardowe roszczenia tokenów o opcjonalne roszczenia, takie jak grupy. Opcja Grupa aplikacji obejmuje grupy przypisane do aplikacji. Opcje Wszystkie lub Grupy zabezpieczeń obejmują grupy z aplikacji w tej samej dzierżawie, które mogą dodawać grupy do tokenu. Oceń efekt, ponieważ może on negatywnie wpływać na wydajność żądań grup w tokenie przez spowodowanie wydmuchania tokenu i wymaganie większej liczby wywołań w celu pobrania grup.

Więcej informacji:

Zalecamy używanie i dołączanie ról aplikacji, którymi klienci zarządzają przy użyciu portalu lub interfejsów API. Przypisz role do użytkowników i grup, aby kontrolować dostęp. Po wystawieniu tokenu przypisane role znajdują się w oświadczeniach ról tokenu. Informacje pochodzące z tokenu uniemożliwiają wywołania większej liczby interfejsów API.

Zobacz Dodaj role aplikacji do swojej aplikacji i odbierz je w tokenie

Dodaj oświadczenia na podstawie informacji o najemcy. Na przykład rozszerzenie ma identyfikator użytkownika specyficznego dla przedsiębiorstwa.

Dodawanie informacji z katalogu do tokenu jest wydajne i zwiększa odporność dzięki zmniejszeniu zależności. Nie pozwala rozwiązać problemów z odpornością z powodu braku możliwości uzyskania tokenu. Dodaj opcjonalne oświadczenia dla podstawowych scenariuszy aplikacji. Jeśli aplikacja wymaga informacji dotyczących funkcji administracyjnych, aplikacja może uzyskać te informacje zgodnie z potrzebami.

Microsoft Graph

Program Microsoft Graph ma ujednolicony punkt końcowy interfejsu API umożliwiający dostęp do danych platformy Microsoft 365 dotyczących wzorców produktywności, tożsamości i zabezpieczeń. Aplikacje korzystające z programu Microsoft Graph mogą używać informacji o usłudze Microsoft 365 do autoryzacji.

Aplikacje wymagają jednego tokenu dostępu do platformy Microsoft 365, który jest bardziej odporny niż poprzednie interfejsy API dla składników platformy Microsoft 365, takich jak Microsoft Exchange lub Microsoft SharePoint, które wymagały wielu tokenów.

W przypadku korzystania z interfejsów API programu Microsoft Graph użyj zestawu SDK programu Microsoft Graph, który upraszcza tworzenie odpornych aplikacji, które uzyskują dostęp do programu Microsoft Graph.

Zobacz Omówienie zestawu Microsoft Graph SDK

W przypadku autoryzacji rozważ użycie oświadczeń tokenu zamiast niektórych wywołań programu Microsoft Graph. Żądaj grup, ról aplikacji i opcjonalnych oświadczeń w tokenach. Program Microsoft Graph do autoryzacji wymaga większej liczby wywołań sieciowych korzystających z platformy tożsamości firmy Microsoft i programu Microsoft Graph. Jeśli jednak aplikacja korzysta z programu Microsoft Graph jako warstwy danych, program Microsoft Graph do autoryzacji nie jest bardziej ryzykowny.

Korzystanie z uwierzytelniania brokera na urządzeniach przenośnych

Na urządzeniach przenośnych broker uwierzytelniania, taki jak Microsoft Authenticator, zwiększa odporność. Broker uwierzytelniania używa podstawowego tokenu odświeżania (PRT) z oświadczeniami dotyczącymi użytkownika i urządzenia. Użyj PRT jako tokenów uwierzytelniania, aby uzyskać dostęp do innych aplikacji z urządzenia. Gdy PRT żąda dostępu do aplikacji, identyfikator Entra firmy Microsoft ufa swojemu urządzeniu i oświadczeniom uwierzytelniania wieloskładnikowego. Zwiększa to odporność, zmniejszając kroki uwierzytelniania urządzenia. Użytkownicy nie są proszeni o podanie wielu monitów uwierzytelniania wieloskładnikowego na tym samym urządzeniu.

Zobacz Co to jest podstawowy token odświeżania?

Diagram aplikacji wywołującej platformę tożsamości firmy Microsoft za pośrednictwem pamięci podręcznej tokenów i magazynu tokenów oraz brokera uwierzytelniania na urządzeniu z uruchomioną aplikacją.

Uwierzytelnianie brokera jest obsługiwane przez bibliotekę MSAL. Więcej informacji:

Ciągła ocena dostępu

Ciągła ocena dostępu (CAE) zwiększa bezpieczeństwo i odporność aplikacji przy użyciu tokenów długotrwałych. W przypadku środowiska CAE token dostępu jest odwołyyowyowyny na podstawie zdarzeń krytycznych i oceny zasad, a nie krótkich okresów istnienia tokenu. W przypadku niektórych interfejsów API zasobów, ponieważ ryzyko i zasady są oceniane w czasie rzeczywistym, funkcja CAE zwiększa okres ważności tokenu do 28 godzin. Biblioteka MSAL (Biblioteka Uwierzetylniania Microsoft) odświeża długoterminowe tokeny.

Więcej informacji:

Jeśli tworzysz interfejsy API zasobów, przejdź do strony openid.netShared Signals — A Secure Webhooks Framework ( Platforma bezpiecznych elementów webhook).

Dalsze kroki