Udostępnij za pośrednictwem

Zarządzanie tokenami dla modelu Zero Trust

W przypadku tworzenia aplikacji Zero Trust ważne jest, aby w szczególności zdefiniować intencję aplikacji i jej wymagania dotyczące dostępu do zasobów. Aplikacja powinna zażądać tylko dostępu wymaganego do działania zgodnie z oczekiwaniami. Ten artykuł ułatwia deweloperom tworzenie zabezpieczeń w aplikacjach przy użyciu tokenów identyfikatorów, tokenów dostępu i tokenówzabezpieczających , które aplikacja może odbierać z platformy tożsamości firmy Microsoft.

Upewnij się, że aplikacja jest zgodna z zasadą zerowego zaufania i najmniejszych uprawnień oraz że zapobiega użyciu sprzecznemu z jej przeznaczeniem. Ogranicz dostęp użytkowników za pomocą zasad Just-In-Time i Just-Enough-Access (JIT/JEA), zasad adaptacyjnych opartych na ryzyku i ochrony danych. Oddzielaj sekcje wrażliwe i zaawansowane aplikacji. Zapewnij tylko autoryzowany dostęp użytkowników do tych obszarów. Ogranicz użytkowników, którzy mogą korzystać z aplikacji i możliwości, które mają w aplikacji.

Wbuduj zasadę najmniejszych uprawnień w sposób, w jaki aplikacja zarządza tokenami identyfikacyjnymi otrzymywanymi z platformy tożsamości firmy Microsoft. Informacje w tokenach identyfikatorów umożliwiają sprawdzenie, czy użytkownik jest tym, kim jest. Użytkownik lub jego organizacja mogą określać warunki uwierzytelniania, takie jak uwierzytelnianie wieloskładnikowe, urządzenia zarządzane i prawidłowe lokalizacje.

Ułatwiaj klientom zarządzanie autoryzacjami w aplikacji. Zmniejszanie nakładu pracy związanego z tworzeniem i konfigurowaniem użytkowników oraz procesami ręcznymi. Automatyczne prowizjonowanie użytkowników umożliwia administratorom IT automatyzowanie tworzenia, zarządzania i usuwania tożsamości użytkowników w docelowych magazynach tożsamości. Klienci mogą wykorzystać automatyzację zmian użytkowników i grup za pomocą aprozwizacji aplikacji lub aprowizacji opartej na HR w usłudze Microsoft Entra ID.

Korzystanie z roszczeń tokenów w aplikacjach

Użyj oświadczeń w tokenach ID, aby poprawić wrażenia użytkownika wewnątrz aplikacji, wykorzystując je jako klucze w bazie danych. Zapewnianie dostępu do aplikacji klienckiej. Token identyfikatora to podstawowe rozszerzenie, które openID Connect (OIDC) wykonuje do protokołu OAuth 2.0. Aplikacja może odbierać tokeny identyfikatorów wraz z tokenami dostępu lub zamiast tokenów dostępu.

W standardowym wzorcu autoryzacji tokenu zabezpieczającego wystawiony token identyfikatora umożliwia aplikacji odbieranie informacji o użytkowniku. Nie używaj tokenu identyfikatora jako procesu autoryzacji w celu uzyskania dostępu do zasobów. Serwer autoryzacji wystawia tokeny identyfikatorów zawierające oświadczenia z informacjami o użytkowniku, które zawierają następujące informacje.

  • Oświadczenie odbiorcy (aud) to identyfikator klienta aplikacji. Zaakceptuj tylko tokeny dla identyfikatora klienta interfejsu API.
  • Atrybut tid jest identyfikatorem dzierżawcy, który wystawił token. Oświadczenie oid jest niezmienną wartością, która jednoznacznie identyfikuje użytkownika. Użyj unikatowej kombinacji tid oświadczeń i oid jako klucza, gdy musisz skojarzyć dane z użytkownikiem. Użyj tych wartości oświadczeń, aby połączyć dane z powrotem z identyfikatorem użytkownika w usłudze Microsoft Entra ID.
  • Oświadczenie sub jest niezmienną wartością, która unikatowo identyfikuje użytkownika. Twierdzenie podmiotu jest również unikatowe dla Twojej aplikacji. Jeśli używasz sub oświadczenia do skojarzenia danych z użytkownikiem, nie można przejść z danych i połączyć je z użytkownikiem w usłudze Microsoft Entra ID.

Twoje aplikacje mogą używać zakresu openid do żądania tokenu identyfikacyjnego z platformy tożsamości Microsoft. Standard OIDC zarządza zakresem openid oraz formatem i zawartością tokenu identyfikacyjnego. OIDC określa następujące zakresy:

  • Użyj zakresu openid, aby zalogować użytkownika i dodać roszczenie sub do tokenu ID. Te zakresy zapewniają identyfikator użytkownika, który jest unikatowy zarówno dla aplikacji, jak i użytkownika, i wywołują endpoint UserInfo.
  • Zakres email dodaje email oświadczenie zawierające adres e-mail użytkownika do tokenu identyfikatora.
  • Zakres profile dodaje oświadczenia z podstawowymi atrybutami profilu użytkownika (nazwa, nazwa użytkownika) do tokenu identyfikatora.
  • Zakres offline_access umożliwia aplikacji dostęp do danych użytkownika nawet wtedy, gdy użytkownik nie jest obecny.

Biblioteka Microsoft Authentication Library (MSAL) zawsze dodaje do każdego żądania tokenu zakresy: openid, email i profile. W związku z tym biblioteka MSAL zawsze zwraca token identyfikatora i token dostępu w każdym wywołaniu metody AcquireTokenSilent lub metody AcquireTokenInteractive. Biblioteka MSAL zawsze żąda zakresu offline_access. Platforma tożsamości firmy Microsoft zawsze zwraca offline_access zakres, nawet jeśli żądana aplikacja nie określa offline_access zakresu.

Firma Microsoft używa standardu OAuth2 do wystawiania tokenów dostępu. Standard OAuth2 mówi, że otrzymujesz token, ale nie określa formatu tokenu ani tego, co musi znajdować się w tokenie. Kiedy Twoja aplikacja musi uzyskać dostęp do zasobu chronionego przez Microsoft Entra ID, powinna użyć zakresu zdefiniowanego przez zasób.

Na przykład Microsoft Graph definiuje zakres User.Read, który autoryzuje aplikację do uzyskania dostępu do pełnego profilu bieżącego użytkownika oraz nazwy dzierżawcy. Program Microsoft Graph definiuje uprawnienia w całym zakresie funkcji dostępnych w tym interfejsie API.

Po autoryzacji platforma tożsamości firmy Microsoft zwraca token dostępu do aplikacji. Podczas wywoływania zasobu aplikacja udostępnia ten token jako część nagłówka autoryzacji żądania HTTP do interfejsu API.

Zarządzanie okresami istnienia tokenu

Aplikacje mogą utworzyć sesję dla użytkownika po pomyślnym zakończeniu uwierzytelniania za pomocą identyfikatora Entra firmy Microsoft. Zarządzanie sesjami użytkowników określa, jak często użytkownik musi powtarzać uwierzytelnianie. Jej rola w zachowaniu jawnie zweryfikowanego użytkownika przed aplikacją z odpowiednimi uprawnieniami i odpowiednim czasem ma kluczowe znaczenie. Okres istnienia sesji musi być oparty na oświadczeniu exp w tokenie identyfikatora. Oświadczenie exp to czas wygaśnięcia tokenu identyfikatora i czas, po którym nie można już używać tokenu do uwierzytelniania użytkownika.

Zawsze przestrzegaj okresu istnienia tokenu , jak podano w odpowiedzi tokenu na tokeny dostępu lub exp oświadczenia w tokenie identyfikatora. Warunki, które zarządzają okresem istnienia tokenu, mogą obejmować częstotliwość logowania dla przedsiębiorstwa. Aplikacja nie może skonfigurować okresu istnienia tokenu. Nie można zażądać okresu istnienia tokenu.

Ogólnie upewnij się, że tokeny są prawidłowe i nieprzeterminowane. Oświadczenie odbiorców (aud) musi być zgodne z identyfikatorem klienta. Upewnij się, że token pochodzi z zaufanego wystawcy. Jeśli masz interfejs API typu wieloodnóstwowy, możesz zdecydować się na filtr, aby tylko określone instancje mogły wywoływać interfejs API. Upewnij się, że wymuszasz okres istnienia tokenu. Sprawdź twierdzenia nbf (nie przed) i exp (wygaśnięcie), aby upewnić się, że bieżący czas mieści się w wartościach tych dwóch twierdzeń.

Nie należy dążyć do wyjątkowo długich ani krótkich okresów istnienia sesji. Aby udzielony czas życia tokenu ID kierował tą decyzją. Utrzymywanie aktywności sesji aplikacji poza ważnością tokenu narusza reguły, zasady i obawy, które skłoniły administratora IT do ustawienia czasu ważności tokenu, aby zapobiec nieautoryzowanemu dostępowi. Krótkie sesje obniżają wydajność użytkownika i niekoniecznie zwiększają stan zabezpieczeń. Popularne frameworki, takie jak ASP.NET, umożliwiają ustawianie czasów zakończenia sesji oraz plików cookie, opierając się na czasie wygaśnięcia tokenów identyfikacji Microsoft Entra ID. Postępuj zgodnie z czasem wygaśnięcia tokenu dostawcy tożsamości, aby upewnić się, że sesje użytkownika nigdy nie są dłuższe niż zasady, które określa dostawca tożsamości.

Buforowanie i odświeżanie tokenów

Pamiętaj, aby odpowiednio buforować tokeny. Biblioteka MSAL automatycznie buforuje tokeny, ale tokeny mają określone okresy ważności. Używaj tokenów przez pełną długość ich okresów istnienia i odpowiednio buforuj je. Jeśli wielokrotnie pytasz o ten sam token, ograniczanie przepustowości powoduje, że aplikacja stanie się mniej elastyczna. Jeśli aplikacja nadużywa wystawiania tokenu, czas wydawania nowych tokenów do aplikacji wydłuża się.

Biblioteki MSAL zarządzają szczegółami protokołu OAuth2, w tym mechaniką odświeżania tokenów. Jeśli nie używasz biblioteki Microsoft Authentication Library (MSAL), upewnij się, że wybrana przez Ciebie biblioteka korzysta z tokenów odświeżających.

Gdy klient uzyskuje token dostępu w celu uzyskania dostępu do chronionego zasobu, otrzymuje token odświeżania. Użyj tokenu odświeżania, aby uzyskać nowe pary tokenów dostępu/odświeżania po wygaśnięciu bieżącego tokenu dostępu. Użyj tokenów odświeżania, aby uzyskać dodatkowe tokeny dostępowe dla innych zasobów. Tokeny odnowienia są powiązane z kombinacją użytkownika i klienta (a nie z zasobem lub dzierżawcą). Możesz użyć tokenu odświeżania, aby uzyskać tokeny dostępu w dowolnej kombinacji zasobów i dzierżawcy, w której aplikacja posiada uprawnienia.

Zarządzanie błędami i usterkami tokenu

Aplikacja nigdy nie powinna próbować weryfikować, dekodować, sprawdzać, interpretować ani badać zawartości tokenu dostępu. Te operacje są ściśle w gestii interfejsu API zasobów. Jeśli aplikacja próbuje zbadać zawartość tokenu dostępu, prawdopodobnie aplikacja nie działa, gdy platforma tożsamości firmy Microsoft wystawia zaszyfrowane tokeny.

Rzadko wywołanie pobierania tokenu kończy się niepowodzeniem z powodu problemów, takich jak awaria sieci, infrastruktury lub usługi uwierzytelniania. Zwiększ odporność środowiska uwierzytelniania w aplikacji, jeśli wystąpi błąd pozyskiwania tokenu, wykonując następujące najlepsze rozwiązania:

  • Lokalna pamięć podręczna i zabezpieczanie tokenów za pomocą szyfrowania.
  • Nie przekazuj artefaktów zabezpieczeń, takich jak tokeny w niezabezpieczonych kanałach.
  • Omówienie wyjątków i odpowiedzi usługi od dostawcy tożsamości i reagowanie na nie.

Deweloperzy często mają pytania dotyczące wglądu w tokeny w celu debugowania problemów, takich jak otrzymanie błędu 401 podczas odwoływania się do zasobu. Ponieważ więcej zaszyfrowanych tokenów uniemożliwia wyszukiwanie wewnątrz tokenu dostępu, należy znaleźć alternatywy dla wyszukiwania wewnątrz tokenów dostępu. W przypadku debugowania odpowiedź tokenu zawierająca token dostępu zawiera potrzebne informacje.

W kodzie sprawdź klasy błędów, a nie poszczególne przypadki błędów. Na przykład, zamiast zajmować się poszczególnymi błędami, skoncentruj się na obsłudze interakcji z użytkownikiem, gdy system nie udziela uprawnień. Ponieważ możesz przegapić te poszczególne przypadki, lepiej jest sprawdzić klasyfikator, taki jak interakcja użytkownika, zamiast zagłębiać się w poszczególne kody błędów.

Może być konieczne cofnięcie się do AcquireTokenInteractive i zapewnienie wyzwań z roszczeniami, których wymaga wywołanie AcquireTokenSilent. Zapewnia to skuteczne zarządzanie żądaniem interakcyjnym.

Następne kroki

  • Last updated on