Udostępnij przez

Zabezpieczanie aplikacji i interfejsów API przez weryfikowanie oświadczeń

Interakcja z tokenami to podstawowy element tworzenia aplikacji do autoryzowania użytkowników. Zgodnie z zasadą zerowego zaufania dla dostępu z najmniejszym uprzywilejowanym dostępem ważne jest, aby aplikacje weryfikowały wartości niektórych oświadczeń znajdujących się w tokenie dostępu podczas wykonywania autoryzacji.

Autoryzacja oparta na oświadczeniach pozwala aplikacjom upewnić się, że token zawiera poprawne wartości dla takich elementów jak dzierżawca, przedmiot i obiekt obecne w tokenie. Mówi się, że autoryzacja oparta na oświadczeniach może wydawać się złożona, biorąc pod uwagę różne metody wykorzystania i scenariuszy do śledzenia. Artykuł ten ma na celu uproszczenie procesu autoryzacji na podstawie roszczeń, aby upewnić się, że Twoje aplikacje przestrzegają najbezpieczniejszych praktyk.

Aby upewnić się, że logika autoryzacji jest bezpieczna, należy zweryfikować następujące informacje w oświadczeniach:

  • Dla tokenu określono odpowiednią grupę odbiorców.
  • Identyfikator klienta tokenu jest zgodny z identyfikatorem klienta, w którym są przechowywane dane.
  • Temat tokenu jest odpowiedni.
  • Aktor (aplikacja kliencka) jest autoryzowany.

Uwaga

Tokeny dostępu są weryfikowane tylko w internetowych interfejsach API, dla których zostały uzyskane przez klienta. Klient nie powinien weryfikować tokenów dostępu.

Aby uzyskać więcej informacji na temat roszczeń wymienionych w tym artykule, zobacz tokeny dostępu platformy tożsamości Microsoft.

Weryfikowanie odbiorców

Oświadczenie aud identyfikuje zamierzonych odbiorców tokenu. Przed zweryfikowaniem oświadczeń należy zawsze sprawdzić, czy wartość aud oświadczenia zawartego w tokenie dostępu jest zgodna z internetowym interfejsem API. Wartość może zależeć od tego, jak klient zażądał tokenu. Odbiorca tokenu dostępu zależy od punktu końcowego.

  • W przypadku tokenów w wersji 2.0 odbiorcą jest identyfikator klienta interfejsu API. Jest to Globalny Unikalny Identyfikator (GUID).
  • W przypadku tokenów w wersji 1.0 odbiorcą jest jeden z identyfikatorów URI aplikacji zgłoszonych w interfejsie API do weryfikacji tokenu. Na przykład api://{ApplicationID}, lub unikatowa nazwa rozpoczynająca się od nazwy domeny (jeśli nazwa domeny jest skojarzona z dzierżawą).

Aby uzyskać więcej informacji na temat identyfikatora URI aplikacji, zobacz Identyfikator URI aplikacji.

Weryfikowanie najemcy

Zawsze sprawdzaj, czy tid element w tokenie jest zgodny z identyfikatorem najemcy używanym do przechowywania danych w aplikacji. Gdy informacje są przechowywane dla aplikacji w kontekście najemcy, należy uzyskać do nich dostęp tylko później w tym samym najemcy. Nigdy nie zezwalaj na dostęp do danych jednego najemcy przez innego najemcę.

Weryfikacja najemcy jest pierwszym krokiem, ale kontrole podmiotu i aktora opisane w tym artykule są nadal niezbędne. Jeśli zamierzasz autoryzować wszystkich użytkowników w dzierżawie, zdecydowanie zaleca się jawne dodanie tych użytkowników do grupy i autoryzowanie na podstawie grupy. Na przykład, sprawdzając tylko identyfikator dzierżawy i obecność oid roszczenia, twój interfejs API może przypadkowo autoryzować wszystkie główne zasady usług w tej dzierżawie, oprócz użytkowników.

Weryfikowanie tematu

Ustal, czy podmiot tokenu, taki jak użytkownik (lub aplikacja dla tokenu tylko dla aplikacji), jest autoryzowany.

Możesz sprawdzić konkretne sub lub oid oświadczenia.

Lub:

Możesz sprawdzić, czy podmiot należy do odpowiedniej roli lub grupy przy użyciu znaczników roles, scp, groups, wids. Na przykład użyj niezmiennych wartości atrybutów tid i oid jako klucza połączonego dla danych aplikacji i określ, czy użytkownik powinien otrzymać dostęp.

Oświadczenia roles, groups lub wids mogą również służyć do określenia, czy podmiot ma autoryzację do wykonania operacji, chociaż nie są wyczerpującą listą wszystkich sposobów udzielania uprawnień podmiotu. Na przykład administrator może mieć uprawnienia do zapisywania w interfejsie API, ale nie normalnego użytkownika, lub użytkownik może być w grupie, która może wykonać jakąś akcję. Uprawnienie wid reprezentuje role na poziomie całej dzierżawy przypisane użytkownikowi z ról dostępnych we wbudowanych rolach Microsoft Entra. Aby uzyskać więcej informacji, zobacz Wbudowane role usługi Microsoft Entra.

Ostrzeżenie

Nigdy nie używaj oświadczeń, takich jak email, preferred_username lub unique_name do przechowywania lub określania, czy użytkownik w tokenie dostępu powinien mieć dostęp do danych. Te oświadczenia nie są unikatowe i mogą być sterowane przez administratorów dzierżawy lub czasami użytkowników, co czyni je nieodpowiednimi do podejmowania decyzji dotyczących autoryzacji. Są one używane tylko do celów wyświetlania. Nie używaj również roszczenia upn w procesie autoryzacji. Chociaż nazwa UPN jest unikatowa, często zmienia się w trakcie istnienia podmiotu zabezpieczeń użytkownika, co sprawia, że jest zawodna do celów autoryzacyjnych.

Weryfikowanie aktora

Aplikacja kliencka działająca w imieniu użytkownika (nazywana aktorem) musi być również autoryzowana. Użyj oświadczenia (zakresu) scp, aby zweryfikować, czy aplikacja ma uprawnienia do wykonania operacji. Uprawnienia w programie scp powinny być ograniczone do tego, czego użytkownik rzeczywiście potrzebuje i przestrzega zasad najniższych uprawnień.

Jednak są przypadki, gdy scp nie występuje w tokenie. Należy sprawdzić brak scp roszczenia w następujących scenariuszach:

  • Uprawnienia tylko dla aplikacji działającej w tle/tylko aplikacji
  • Tokeny identyfikacyjne

Aby uzyskać więcej informacji na temat zakresów i uprawnień, zobacz Zakresy i uprawnienia w Platforma tożsamości Microsoft.

Uwaga

Aplikacja może obsługiwać tokeny wyłącznie dla aplikacji (żądania z aplikacji bez użytkowników, takie jak aplikacje demona) i chcieć autoryzować określoną aplikację w wielu dzierżawach, zamiast poszczególnych identyfikatorów głównych usług. W takim przypadku appid oświadczenia (dla tokenów w wersji 1.0) lub azp oświadczenia (dla tokenów w wersji 2.0) można użyć do autoryzacji podmiotu. Jednak w przypadku korzystania z tych oświadczeń aplikacja musi upewnić się, że token został wystawiony bezpośrednio dla aplikacji, sprawdzając opcjonalne oświadczenie idtyp. W ten sposób można autoryzować tylko tokeny typu app , ponieważ delegowane tokeny użytkownika mogą być potencjalnie uzyskiwane przez jednostki inne niż aplikacja.

Następne kroki

  • Last updated on