Zarządzanie tokenami dla zera zaufania

  • Artykuł

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 deweloperowi tworzenie zabezpieczeń w aplikacjach przy użyciu tokenów identyfikatorów, tokenów dostępu i tokenów zabezpieczających, które aplikacja może odbierać z Platforma tożsamości Microsoft.

Upewnij się, że aplikacja jest zgodna z zasadą zerowego zaufania najniższych uprawnień i zapobiega użyciu w sposób, który narusza intencję. 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. Rozdziel poufne i zaawansowane sekcje aplikacji, zapewniając 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.

Utwórz najmniejsze uprawnienia, aby dowiedzieć się, jak aplikacja zarządza tokenami identyfikatorów odbieranych z Platforma tożsamości 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 dostarczanie uwierzytelniania wieloskładnikowego, korzystanie z zarządzanego urządzenia i bycie w prawidłowej lokalizacji.

Ułatwiaj klientom zarządzanie autoryzacjami w aplikacji. Zmniejsz nakład pracy związany z aprowizację użytkowników i potrzeba ręcznego przetwarzania. Automatyczna aprowizacja użytkowników umożliwia administratorom IT automatyzowanie tworzenia, konserwacji i usuwania tożsamości użytkowników w docelowych magazynach tożsamości. Klienci mogą bazować na automatyzacjach zmian użytkowników i grup przy użyciu aprowizacji aplikacji lub aprowizacji opartej na kadrach w usłudze Microsoft Entra ID.

Używanie oświadczeń tokenów w aplikacjach

Używaj oświadczeń w tokenach identyfikatorów środowiska użytkownika wewnątrz aplikacji, jako kluczy w bazie danych i zapewniania dostępu do aplikacji klienckiej. Token identyfikatora jest podstawowym rozszerzeniem, które openID Połączenie (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 odbiorców (aud) to identyfikator klienta aplikacji. Zaakceptuj tylko tokeny dla identyfikatora klienta interfejsu API.
  • Oświadczenie tid jest identyfikatorem dzierżawy, która wystawiła 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. Możesz użyć 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. Oświadczenie podmiotu jest również unikatowe dla 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.

Aplikacje mogą używać openid zakresu do żądania tokenu identyfikatora z Platforma tożsamości Microsoft. Standard OIDC zarządza openid zakresem wraz z formatem i zawartością tokenu identyfikatora. OIDC określa następujące zakresy:

  • openid Użyj zakresu, aby zalogować się do użytkownika i dodać sub oświadczenie do tokenu identyfikatora. Te zakresy zapewniają identyfikator użytkownika, który jest unikatowy dla aplikacji, a użytkownik i wywołuje punkt końcowy 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 identyfikator openid, email i profile zakresy do każdego żądania tokenu. W związku z tym biblioteka MSAL zawsze zwraca token identyfikatora i token dostępu w każdym wywołaniu metody AcquireTokenSilent Lub AcquireTokenInteractive. Biblioteka MSAL zawsze żąda offline_access zakresu. Platforma tożsamości 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. Gdy aplikacja musi uzyskać dostęp do zasobu chronionego przez identyfikator Entra firmy Microsoft, powinien użyć zakresu zdefiniowanego przez zasób.

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

Po autoryzacji Platforma tożsamości 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 potrzebuje ponownego uwierzytelniania. 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 rzecz biorąc, tokeny muszą być prawidłowe i niewyświetłe. Oświadczenie odbiorców (aud) musi być zgodne z identyfikatorem klienta. Upewnij się, że token pochodzi z zaufanego wystawcy. Jeśli masz wielodostępny interfejs API, możesz wybrać filtrowanie, aby tylko określone dzierżawy mogły wywoływać interfejs API. Upewnij się, że wymuszasz okres istnienia tokenu. nbf Sprawdź oświadczenia (nie przed) i exp (wygaśnięcie), aby upewnić się, że bieżący czas mieści się w wartościach tych dwóch oświadczeń.

Nie należy dążyć do wyjątkowo długich ani krótkich okresów istnienia sesji. Niech udzielony token identyfikatora okresu istnienia będzie napędzać 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 platformy, takie jak ASP.NET, umożliwiają ustawianie limitów czasu sesji i plików cookie z czasu wygaśnięcia tokenu identyfikatora entra firmy Microsoft. Po upływie czasu wygaśnięcia tokenu dostawcy tożsamości gwarantuje, że sesje użytkownika nigdy nie będą 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ą okresy istnienia. 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 wymagany do wystawiania nowych tokenów do wydłużenia aplikacji.

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

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ępu dla innych zasobów. Tokeny odświeżania są powiązane z kombinacją użytkownika i klienta (nie do zasobu lub dzierżawy). Możesz użyć tokenu odświeżania, aby uzyskać tokeny dostępu w dowolnej kombinacji zasobów i dzierżawy, w której aplikacja ma 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 odpowiedzialne za interfejs API zasobów. Jeśli aplikacja próbuje zbadać zawartość tokenu dostępu, prawdopodobnie aplikacja nie działa, gdy Platforma tożsamości Microsoft wystawia zaszyfrowane tokeny.

Rzadko wywołanie pobierania tokenu może zakończyć się niepowodzeniem z powodu problemów, takich jak awaria sieci, infrastruktury lub usługi uwierzytelniania lub awaria. 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 wyszukiwania tokenów w celu debugowania problemów, takich jak odbieranie błędu 401 podczas wywoływania zasobu. Ponieważ więcej zaszyfrowanych tokenów uniemożliwia wyszukiwanie wewnątrz tokenu dostępu, potrzebne są 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 obsługa interakcji z użytkownikiem jest wymagana, a nie poszczególne błędy, w których system nie udzielił 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 powrót do AcquireTokenInteractive i zapewnienie oświadczeń wyzwania, których wymaga wywołanie AcquireTokenSilent . Dzięki temu skuteczne zarządzanie żądaniem interakcyjnym.

Następne kroki