Udostępnij za pośrednictwem

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

  • Artykuł

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 umożliwia aplikacjom zapewnienie, że token zawiera poprawne wartości dla takich elementów jak dzierżawa, temat i aktor znajdujący się 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. W tym artykule zamierzasz uprościć proces autoryzacji opartej na oświadczeniach, aby zapewnić, że aplikacje są zgodne z najbezpieczniejszymi rozwiązaniami.

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 dzierżawy tokenu jest zgodny z identyfikatorem dzierżawy, w której 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 oświadczeń wymienionych w tym artykule, zobacz Platforma tożsamości Microsoft tokeny dostępu.

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. Odbiorcy tokenu dostępu zależą od punktu końcowego:

  • W przypadku tokenów w wersji 2.0 odbiorcy są identyfikatorem klienta internetowego interfejsu API. Jest to identyfikator GUID.
  • W przypadku tokenów w wersji 1.0 odbiorcy są jednym z identyfikatorów URI identyfikatorów aplikacji zadeklarowanych w internetowym interfejsie API, który weryfikuje token. 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 identyfikatora aplikacji, zobacz Identyfikator URI aplikacji.

Weryfikowanie dzierżawy

Zawsze sprawdzaj, czy tid element w tokenie jest zgodny z identyfikatorem dzierżawy używanym do przechowywania danych z aplikacją. Gdy informacje są przechowywane dla aplikacji w kontekście dzierżawy, należy uzyskać do niej dostęp tylko później w tej samej dzierżawie. Nigdy nie zezwalaj na dostęp do danych w jednej dzierżawie z innej dzierżawy.

Weryfikacja dzierżawy jest tylko pierwszym krokiem, a kontrole tematów i aktorów opisanych w tym artykule są nadal wymagane. Jeśli twoim zamiarem jest autoryzowanie 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 oświadczenia, interfejs API może przypadkowo autoryzować wszystkie jednostki usługi 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 rolesoświadczeń , , groupsscpwids . Na przykład użyj niezmiennych wartości tid oświadczeń i oid jako klucza połączonego dla danych aplikacji i określ, czy użytkownik powinien otrzymać dostęp.

groups Oświadczenia roleslub 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ę. Oświadczenie wid reprezentuje role całej dzierżawy przypisane do użytkownika z ról znajdujących się we wbudowanych rolach firmy 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 sprawia, że są one nieodpowiednie do podejmowania decyzji dotyczących autoryzacji. Są one używane tylko do celów wyświetlania. Nie należy również używać upn oświadczenia do autoryzacji. Chociaż nazwa UPN jest unikatowa, często zmienia się w okresie istnienia podmiotu zabezpieczeń użytkownika, co sprawia, że jest zawodny do autoryzacji.

Weryfikowanie aktora

Aplikacja kliencka działająca w imieniu użytkownika (nazywana aktorem) musi być również autoryzowana. scp Użyj oświadczenia (zakresu), aby sprawdzić, 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ń.

Istnieją jednak wystąpienia, w których scp token nie występuje. Należy sprawdzić brak scp roszczenia w następujących scenariuszach:

  • Uprawnienia tylko do aplikacji demona/aplikacji
  • Tokeny identyfikatorów

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 tylko dla aplikacji (żądania z aplikacji bez użytkowników, takie jak aplikacje demona) i chcieć autoryzować określoną aplikację w wielu dzierżawach, a nie poszczególne identyfikatory jednostki usługi. 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 idtyp opcjonalne oświadczenie. 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