Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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:
- Omówienie biblioteki uwierzytelniania firmy Microsoft
- Co to jest platforma tożsamości firmy Microsoft?
- Dokumentacja platformy tożsamości firmy Microsoft
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:
Serializacja niestandardowej pamięci podręcznej tokenów w MSAL dla Java
Niestandardowa serializacja pamięci podręcznej tokenów w bibliotece MSAL dla języka Python.
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:
microsoft-authentication-library-for-jsmicrosoft-authentication-library-for-dotnetmicrosoft-authentication-library-for-pythonmicrosoft-authentication-library-for-javamicrosoft-authentication-library-for-objcmicrosoft-authentication-library-for-androidmicrosoft-identity-web
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.
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.
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.
Pobieranie informacji związanych z autoryzacją
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:
- Tokeny identyfikatorów platformy tożsamości firmy Microsoft
- Tokeny dostępu platformy tożsamości firmy Microsoft
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?
Uwierzytelnianie brokera jest obsługiwane przez bibliotekę MSAL. Więcej informacji:
- Jednokrotne logowanie (SSO) za pośrednictwem brokera uwierzytelniania w systemie iOS
- Włączanie logowania jednokrotnego między aplikacjami w systemie Android przy użyciu biblioteki MSAL
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:
- Ciągła ocena dostępu
- Zabezpieczanie aplikacji przy użyciu oceny ciągłego dostępu
- Ocena zdarzeń krytycznych
- Ocena zasad dostępu warunkowego
- Jak używać interfejsów API z włączoną obsługą CAE w aplikacjach
Jeśli tworzysz interfejsy API zasobów, przejdź do strony openid.netShared Signals — A Secure Webhooks Framework ( Platforma bezpiecznych elementów webhook).
Dalsze kroki
- Jak używać interfejsów API z włączoną obsługą CAE w aplikacjach
- Zwiększ odporność uwierzytelniania i autoryzacji w aplikacjach demona, które tworzysz
- Budować odporność w infrastrukturze zarządzania tożsamościami i dostępem
- Buduj odporność systemu w zarządzaniu tożsamościami klientów oraz dostępem za pomocą usługi Azure AD B2C