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

Artykuł
10/24/2023

Dowiedz się, jak tworzyć odporność na aplikacje klienckie korzystające z identyfikatora Platforma tożsamości Microsoft i Microsoft Entra do logowania użytkowników oraz wykonywać akcje w imieniu tych użytkowników.

Korzystanie z biblioteki Microsoft Authentication Library (MSAL)

Biblioteka Microsoft Authentication Library (MSAL) jest częścią Platforma tożsamości Microsoft. Biblioteka MSAL uzyskuje, zarządza, buforuje i odświeża tokeny; używa najlepszych rozwiązań w zakresie odporności. Biblioteka MSAL ułatwia deweloperom tworzenie bezpiecznych rozwiązań.

Więcej informacji:

Biblioteka MSAL buforuje tokeny i używa wzorca pozyskiwania tokenu dyskretnego. Biblioteka MSAL serializuje pamięć podręczną tokenów w systemach operacyjnych, które natywnie zapewniają bezpieczny magazyn, taki jak platforma uniwersalna systemu Windows (UWP), iOS i Android. Dostosuj zachowanie serializacji w przypadku korzystania z następujących elementów:

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, Platforma tożsamości Microsoft przykłady kodu.

C#
JavaScript

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

return myMSALObj.acquireTokenSilent(request).catch(error => {
    console.warn("silent token acquisition fails. acquiring token using redirect");
    if (error instanceof msal.InteractionRequiredAuthError) {
        // fallback to interaction when silent call fails
        return myMSALObj.acquireTokenPopup(request).then(tokenResponse => {
            console.log(tokenResponse);

            return tokenResponse;
        }).catch(error => {
            console.error(error);
        });
    } else {
        console.warn(error);
    }
});

Biblioteka MSAL może odświeżać tokeny. Gdy Platforma tożsamości 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 prawidłowy, ale pozyskiwanie 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. Ta praktyka jest używana w przypadku bibliotek w ramach programowania i zwiększania odporności aplikacji.

Znajdź najnowszą wersję i informacje o wersji:

Wzorce odporne na potrzeby 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. Biblioteka 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.

Tokeny pamięci podręcznej

Upewnij się, że tokeny pamięci podręcznej aplikacji są dokładnie buforowane z Platforma 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 wywołanie aplikacji w celu Platforma tożsamości 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 Platforma tożsamości 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 serializują pamięć podręczną tokenów bezpiecznie, aby utrwał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 w Platforma tożsamości 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 środowisko użytkownika z najmniejszymi zależnościami to uzyskiwanie tokenu dyskretnego.

Diagram usług Platforma tożsamości 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 użytkownika. Jeśli to możliwe, Platforma tożsamości Microsoft udostępnia token aplikacji bez interakcji z użytkownikiem. Jeśli żadna metoda nie powoduje tokenu, użytkownik ręcznie ponownie uwierzytelnia.

Uwaga

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 o błędach wpływające na odporność. Jeśli aplikacja odbiera kod odpowiedzi HTTP 429, Zbyt wiele żądań, Platforma tożsamości 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, zanim zostanie ukończony czas pola Retry-After odpowiedzi. Często odpowiedź 429 wskazuje, że aplikacja nie buforuje i prawidłowo ponownie korzysta z 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 zostanie wyświetlony nagłówek Retry-After, zaimplementuj ponawianie wykładniczego ponawiania z pierwszą ponowną próbą, co najmniej 5 sekund po odpowiedzi.

Po upłynął limit czasu żądania, natychmiastowe ponawianie prób jest odradzane. Zaimplementuj ponowienie ponawiania wykładniczego, przy pierwszym ponowieniu próby 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 oświadczenia tokenu, ponieważ uniemożliwia to inne wywołanie sieciowe. Mniejsza liczba wywołań sieciowych równa się lepszej odporności.

Więcej informacji:

Uwaga

Niektóre aplikacje nazywają punkt końcowy UserInfo w celu pobrania oświadczeń dotyczących uwierzytelnioowanego użytkownika. Informacje w tokenie identyfikatora są nadzbiorem informacji z punktu końcowego UserInfo. Włącz aplikacjom używanie tokenu identyfikatora zamiast wywoływania punktu końcowego UserInfo.

Rozszerzanie standardowych oświadczeń tokenów przy użyciu opcjonalnych oświadczeń, takich 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 Dodawanie ról aplikacji do aplikacji i odbieranie ich w tokenie

Dodaj oświadczenia na podstawie informacji o dzierżawie. 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. Żądania 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 Platforma tożsamości 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 żądania PRT dla tokenów uwierzytelniania, aby uzyskać dostęp do innych aplikacji z urządzenia. Gdy żądanie PRT żąda dostępu do aplikacji, identyfikator Entra firmy Microsoft ufa swoim urządzeniu i oświadczeniami 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 Platforma tożsamości Microsoft, za pośrednictwem pamięci podręcznej tokenu i magazynu tokenów oraz brokera uwierzytelniania na urządzeniu z uruchomioną aplikacją.

Biblioteka MSAL obsługuje uwierzytelnianie brokera. 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 istnienia tokenu do 28 godzin. Biblioteka MSAL odświeża długotrwałe tokeny.

Więcej informacji:

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

Udostępnij za pośrednictwem

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