Udostępnij za pośrednictwem

Omówienie uprawnień i zgody w Platforma tożsamości Microsoft

  • Artykuł

Aby uzyskać dostęp do chronionego zasobu, takiego jak poczta e-mail lub dane kalendarza, aplikacja wymaga autoryzacji właściciela zasobu. Właściciel zasobu może wyrazić zgodę na żądanie aplikacji lub go odrzucić. Zrozumienie tych podstawowych pojęć pomoże Ci w tworzeniu bezpieczniejszych i godnych zaufania aplikacji, które żądają dostępu, którego potrzebują, gdy ich potrzebują, od użytkowników i administratorów.

Scenariusze dostępu

Jako deweloper aplikacji musisz określić, jak Twoja aplikacja będzie uzyskiwać dostęp do danych. Aplikacja może używać dostępu delegowanego, działającego w imieniu zalogowanego użytkownika lub dostępu tylko do aplikacji, działającego tylko jako własna tożsamość aplikacji.

Obraz przedstawia ilustrację scenariuszy dostępu.

Dostęp delegowany (dostęp w imieniu użytkownika)

W tym scenariuszu dostępu użytkownik zalogował się do aplikacji klienckiej. Aplikacja kliencka uzyskuje dostęp do zasobu w imieniu użytkownika. Dostęp delegowany wymaga uprawnień delegowanych. Zarówno klient, jak i użytkownik muszą być autoryzowani oddzielnie, aby wysłać żądanie. Aby uzyskać więcej informacji na temat scenariusza dostępu delegowanego, zobacz scenariusz dostępu delegowanego.

W przypadku aplikacji klienckiej należy udzielić odpowiednich delegowanych uprawnień. Uprawnienia delegowane mogą być również określane jako zakresy. Zakresy to uprawnienia dla danego zasobu reprezentującego, do czego aplikacja kliencka może uzyskiwać dostęp w imieniu użytkownika. Aby uzyskać więcej informacji na temat zakresów, zobacz zakresy i uprawnienia.

W przypadku użytkownika autoryzacja opiera się na uprawnieniach, które użytkownik otrzymał w celu uzyskania dostępu do zasobu. Na przykład użytkownik może być autoryzowany do uzyskiwania dostępu do zasobów katalogu przez kontrolę dostępu opartą na rolach (RBAC) firmy Microsoft lub uzyskać dostęp do zasobów poczty i kalendarza przez kontrolę dostępu opartą na rolach w usłudze Exchange Online. Aby uzyskać więcej informacji na temat kontroli dostępu opartej na rolach dla aplikacji, zobacz Kontrola dostępu oparta na rolach dla aplikacji.

Dostęp tylko do aplikacji (dostęp bez użytkownika)

W tym scenariuszu dostępu aplikacja działa samodzielnie bez logowania użytkownika. Dostęp do aplikacji jest używany w scenariuszach, takich jak automatyzacja i tworzenie kopii zapasowych. Ten scenariusz obejmuje aplikacje, które działają jako usługi w tle lub demony. Jest to odpowiednie, gdy niepożądane jest zalogowanie określonego użytkownika lub gdy wymagane dane nie mogą być ograniczone do jednego użytkownika. Aby uzyskać więcej informacji na temat scenariusza dostępu tylko do aplikacji, zobacz Dostęp tylko do aplikacji.

Dostęp tylko do aplikacji używa ról aplikacji zamiast zakresów delegowanych. Po udzieleniu zgody role aplikacji mogą być również nazywane uprawnieniami aplikacji. Aplikacja kliencka musi mieć przyznane odpowiednie uprawnienia aplikacji zasobu, do których jest wywoływana. Po udzieleniu tej funkcji aplikacja kliencka może uzyskiwać dostęp do żądanych danych. Aby uzyskać więcej informacji na temat przypisywania ról aplikacji do aplikacji klienckich, zobacz Przypisywanie ról aplikacji do aplikacji.

Typy uprawnień

Uprawnienia delegowane są używane w scenariuszu dostępu delegowanego. Są to uprawnienia, które umożliwiają aplikacji działanie w imieniu użytkownika. Aplikacja nigdy nie będzie mogła uzyskać dostępu do niczego, do czego zalogowany użytkownik nie mógł uzyskać dostępu.

Na przykład weź aplikację, która otrzymała Files.Read.All delegowane uprawnienie w imieniu użytkownika. Aplikacja będzie mogła odczytywać tylko pliki, do których użytkownik może uzyskać dostęp osobisty.

Uprawnienia aplikacji, znane również jako role aplikacji, są używane w scenariuszu dostępu tylko do aplikacji bez obecności zalogowanego użytkownika. Aplikacja będzie mogła uzyskiwać dostęp do wszelkich danych, z którymi jest skojarzone uprawnienie.

Na przykład aplikacja, która przyznała uprawnienie Files.Read.All aplikacji interfejsu API programu Microsoft Graph, będzie mogła odczytać dowolny plik w dzierżawie przy użyciu programu Microsoft Graph. Ogólnie rzecz biorąc, tylko administrator lub właściciel jednostki usługi interfejsu API może wyrazić zgodę na uprawnienia aplikacji uwidocznione przez ten interfejs API.

Porównanie uprawnień delegowanych i aplikacji

Typy uprawnień Uprawnienia delegowane Uprawnienia aplikacji
Typy aplikacji Aplikacja internetowa/mobilna/jednostronicowa (SPA) Sieć Web / demon
Kontekst dostępu Uzyskiwanie dostępu w imieniu użytkownika Uzyskiwanie dostępu bez użytkownika
Kto może wyrazić zgodę — Użytkownicy mogą wyrazić zgodę na swoje dane
— Administratorzy mogą wyrazić zgodę na wszystkich użytkowników		 Tylko administrator może wyrażać zgodę
Metody wyrażania zgody — Statyczna: skonfigurowana lista rejestracji aplikacji
- Dynamiczne: żądanie indywidualnych uprawnień podczas logowania		 — TYLKO statyczny: skonfigurowana lista rejestracji aplikacji
Inne nazwy -Zakresów
- Zakresy uprawnień OAuth2		 - Role aplikacji
— Uprawnienia tylko do aplikacji
Wynik zgody (specyficzny dla programu Microsoft Graph) OAuth2PermissionGrant Przypisanie appRoleAssignment

Jednym ze sposobów udzielania uprawnień przez aplikacje jest zgoda. Zgoda to proces, w którym użytkownicy lub administratorzy autoryzować aplikację do uzyskiwania dostępu do chronionego zasobu. Na przykład gdy użytkownik próbuje zalogować się do aplikacji po raz pierwszy, aplikacja może zażądać uprawnień do wyświetlenia profilu użytkownika i odczytania zawartości skrzynki pocztowej użytkownika. Użytkownik widzi listę uprawnień, których aplikacja żąda za pośrednictwem monitu o wyrażenie zgody. Inne scenariusze, w których użytkownicy mogą zobaczyć monit o wyrażenie zgody, obejmują:

  • Gdy wcześniej udzielono zgody, zostanie odwołana.
  • Gdy aplikacja jest kodowana, aby w szczególności monitować o zgodę podczas logowania.
  • Gdy aplikacja używa dynamicznej zgody, aby poprosić o nowe uprawnienia zgodnie z potrzebami w czasie wykonywania.

Kluczowe szczegóły monitu o wyrażenie zgody to lista uprawnień wymaganych przez aplikację i informacje o wydawcy. Aby uzyskać więcej informacji na temat monitu o wyrażenie zgody i środowiska wyrażania zgody dla administratorów i użytkowników końcowych, zobacz Środowisko zgody aplikacji.

Zgoda użytkownika występuje, gdy użytkownik próbuje zalogować się do aplikacji. Użytkownik podaje swoje poświadczenia logowania, które są sprawdzane, aby określić, czy udzielono już zgody. Jeśli nie istnieje żaden poprzedni rekord zgody użytkownika lub administratora dla wymaganych uprawnień, zostanie wyświetlony monit o wyrażenie zgody i poproszony o udzielenie aplikacji żądanych uprawnień. Administrator może być zobowiązany do udzielenia zgody w imieniu użytkownika.

W zależności od wymaganych uprawnień niektóre aplikacje mogą wymagać, aby administrator był tym, który udziela zgody. Na przykład uprawnienia aplikacji i wiele uprawnień delegowanych o wysokim poziomie uprawnień mogą być wyrażane tylko przez administratora.

Administratorzy mogą udzielić zgody dla siebie lub całej organizacji. Aby uzyskać więcej informacji na temat zgody użytkownika i administratora, zobacz Omówienie zgody użytkownika i administratora.

Żądania uwierzytelniania są monitowane o zgodę administratora, jeśli nie udzielono zgody i jeśli zażądano jednego z tych uprawnień o wysokim poziomie uprawnień.

Żądania uprawnień, które zawierają niestandardowe zakresy aplikacji, nie są uznawane za wysokie uprawnienia, a tym samym nie wymagają zgody administratora.

Wstępne uwierzytelnianie

Wstępne uwierzytelnianie umożliwia właścicielowi aplikacji zasobów udzielanie uprawnień bez konieczności wyświetlania monitu o zgodę dla tego samego zestawu uprawnień, które zostały wstępnie uwierzytelnione. W ten sposób aplikacja, która została wstępnie uwierzytelniona, nie będzie prosić użytkowników o zgodę na uprawnienia. Właściciele zasobów mogą wstępnie uwierzytelniać aplikacje klienckie w witrynie Azure Portal lub przy użyciu programu PowerShell i interfejsów API, takich jak Microsoft Graph.

Inne systemy autoryzacji

Struktura zgody jest tylko jednym ze sposobów, w jaki aplikacja lub użytkownik może mieć autoryzację dostępu do chronionych zasobów. Administratorzy powinni mieć świadomość innych systemów autoryzacji, które mogą udzielić dostępu do poufnych informacji. Przykłady różnych systemów autoryzacji w firmie Microsoft obejmują wbudowane role Entra, kontrolę dostępu na podstawie ról platformy Azure, kontrolę dostępu na podstawie ról programu Exchange i zgodę specyficzną dla zasobów usługi Teams.

Zobacz też