Słownik: Platforma tożsamości Microsoft
Te terminy są widoczne podczas korzystania z naszej dokumentacji, centrum administracyjnego firmy Microsoft Entra, naszych bibliotek uwierzytelniania i interfejsu API programu Microsoft Graph. Niektóre terminy są specyficzne dla firmy Microsoft, podczas gdy inne są powiązane z protokołami, takimi jak OAuth lub inne technologie używane z Platforma tożsamości Microsoft.
Token dostępu
Typ tokenu zabezpieczającego wystawionego przez serwer autoryzacji i używany przez aplikację kliencką do uzyskiwania dostępu do chronionego serwera zasobów. Zazwyczaj w postaci tokenu internetowego JSON (JWT) token uosabia autoryzację udzieloną klientowi przez właściciela zasobu dla żądanego poziomu dostępu. Token zawiera wszystkie odpowiednie oświadczenia dotyczące podmiotu, umożliwiając aplikacji klienckiej używanie jej jako formy poświadczeń podczas uzyskiwania dostępu do danego zasobu. Eliminuje to również konieczność udostępnienia poświadczeń klientowi przez właściciela zasobu.
Tokeny dostępu są ważne tylko przez krótki czas i nie można ich odwołać. Serwer autoryzacji może również wystawiać token odświeżania po wystawieniu tokenu dostępu. Tokeny odświeżania są zwykle dostarczane tylko do poufnych aplikacji klienckich.
Tokeny dostępu są czasami określane jako "User+App" lub "App-Only", w zależności od reprezentowanych poświadczeń. Na przykład gdy aplikacja kliencka używa następującego elementu:
- Udzielenie autoryzacji "Kod autoryzacji", użytkownik końcowy uwierzytelnia się najpierw jako właściciel zasobu, delegując autoryzację do klienta w celu uzyskania dostępu do zasobu. Klient uwierzytelnia się później podczas uzyskiwania tokenu dostępu. Token może być czasami określany bardziej szczegółowo jako token "User+App", ponieważ reprezentuje zarówno użytkownika, który autoryzował aplikację kliencką, jak i aplikację.
- Udzielanie autoryzacji "Poświadczenia klienta", klient zapewnia jedyne uwierzytelnianie, działające bez uwierzytelniania/autoryzacji właściciela zasobu, dzięki czemu token może być czasami określany jako token "Tylko aplikacja".
Aby uzyskać więcej informacji, zobacz dokumentację tokenów dostępu.
Aktor
Inny termin dla aplikacji klienckiej. Aktor jest stroną działającą w imieniu podmiotu (właściciela zasobu).
Identyfikator aplikacji (klient)
Identyfikator aplikacji lub identyfikator klienta to wartość, którą Platforma tożsamości Microsoft przypisuje do aplikacji podczas rejestrowania jej w identyfikatorze Entra firmy Microsoft. Identyfikator aplikacji to wartość identyfikatora GUID, która jednoznacznie identyfikuje aplikację i jej konfigurację na platformie tożsamości. Identyfikator aplikacji jest dodany do kodu aplikacji, a biblioteki uwierzytelniania zawierają wartość w żądaniach do platformy tożsamości w czasie wykonywania aplikacji. Identyfikator aplikacji (klienta) nie jest wpisem tajnym — nie używaj go jako hasła ani innych poświadczeń.
Manifest aplikacji
Manifest aplikacji to funkcja, która tworzy reprezentację JSON konfiguracji tożsamości aplikacji, używaną jako mechanizm aktualizowania skojarzonych jednostek Application i ServicePrincipal . Aby uzyskać więcej informacji, zobacz Understanding the Microsoft Entra application manifest (Omówienie manifestu aplikacji Entra firmy Microsoft).
Obiekt aplikacji
Podczas rejestrowania/aktualizowania aplikacji zarówno obiekt aplikacji, jak i odpowiedni obiekt jednostki usługi są tworzone/aktualizowane dla tej dzierżawy. Obiekt aplikacji definiuje konfigurację tożsamości aplikacji globalnie (we wszystkich dzierżawach, w których ma dostęp), podając szablon, z którego pochodzą odpowiednie obiekty jednostki usługi do użytku lokalnego w czasie wykonywania (w określonej dzierżawie).
Aby uzyskać więcej informacji, zobacz Application and Service Principal Objects (Obiekty aplikacji i jednostki usługi).
Rejestrowanie aplikacji
Aby umożliwić aplikacji integrację z funkcjami zarządzania tożsamościami i dostępem i delegować je do identyfikatora Entra firmy Microsoft, należy ją zarejestrować w dzierżawie firmy Microsoft Entra. Podczas rejestrowania aplikacji w usłudze Microsoft Entra ID udostępniasz konfigurację tożsamości dla aplikacji, umożliwiając jej integrację z identyfikatorem Entra firmy Microsoft i korzystanie z takich funkcji jak:
- Niezawodne zarządzanie logowaniem jednokrotnym przy użyciu usługi Microsoft Entra Identity Management i implementacji protokołu OpenID Connect
- Dostęp obsługiwany przez brokera do chronionych zasobów przez aplikacje klienckie za pośrednictwem serwera autoryzacji OAuth 2.0
- Struktura wyrażania zgody na zarządzanie dostępem klienta do chronionych zasobów na podstawie autoryzacji właściciela zasobu.
Aby uzyskać więcej informacji, zobacz Integrowanie aplikacji z identyfikatorem Entra firmy Microsoft.
Uwierzytelnianie
Akt zakwestionowania strony dla uzasadnionych poświadczeń, zapewniając podstawę utworzenia podmiotu zabezpieczeń, który ma być używany do obsługi tożsamości i kontroli dostępu. Na przykład podczas udzielania autoryzacji protokołu OAuth 2.0 uwierzytelnianie strony wypełnia rolę właściciela zasobu lub aplikacji klienckiej, w zależności od używanego udzielenia.
Autoryzacja
Czynność udzielania uwierzytelnionego podmiotu zabezpieczeń uprawnień do wykonania czegoś. Istnieją dwa podstawowe przypadki użycia w modelu programowania Entra firmy Microsoft:
- Podczas przepływu udzielania autoryzacji OAuth 2.0: gdy właściciel zasobu udziela autoryzacji aplikacji klienckiej, co umożliwia klientowi dostęp do zasobów właściciela zasobu.
- Podczas dostępu do zasobów przez klienta: zgodnie z implementacją serwera zasobów przy użyciu wartości oświadczeń znajdujących się w tokenie dostępu w celu podejmowania decyzji dotyczących kontroli dostępu na ich podstawie.
Kod autoryzacji
Krótkotrwała wartość dostarczana przez punkt końcowy autoryzacji do aplikacji klienckiej podczas przepływu udzielania kodu autoryzacji OAuth 2.0, jednego z czterech dotacji autoryzacji OAuth 2.0. Nazywany również kodem uwierzytelniania kod autoryzacji jest zwracany do aplikacji klienckiej w odpowiedzi na uwierzytelnianie właściciela zasobu. Kod uwierzytelniania wskazuje, że właściciel zasobu ma delegowanie autoryzacji do aplikacji klienckiej w celu uzyskania dostępu do swoich zasobów. W ramach przepływu kod uwierzytelniania jest później zrealizowany dla tokenu dostępu.
Punkt końcowy autoryzacji
Jeden z punktów końcowych zaimplementowanych przez serwer autoryzacji używany do interakcji z właścicielem zasobu w celu udzielenia autoryzacji podczas przepływu udzielania autoryzacji OAuth 2.0. W zależności od używanego przepływu udzielania autoryzacji podane rzeczywiste udzielenie może się różnić, w tym kodu autoryzacji lub tokenu zabezpieczającego.
Aby uzyskać więcej informacji, zobacz sekcje typów udzielania autoryzacji specyfikacji OAuth 2.0 i punktów końcowych autoryzacji oraz specyfikację OpenIDConnect.
Udzielanie autoryzacji
Poświadczenie reprezentujące autoryzację właściciela zasobu w celu uzyskania dostępu do chronionych zasobów udzielonych aplikacji klienckiej. Aplikacja kliencka może używać jednego z czterech typów dotacji zdefiniowanych przez strukturę autoryzacji OAuth 2.0 w celu uzyskania dotacji, w zależności od typu klienta/wymagań: "udzielanie kodu autoryzacji", "udzielanie poświadczeń klienta", "udzielanie niejawne" i "udzielanie poświadczeń hasła właściciela zasobu". Poświadczenie zwrócone do klienta jest tokenem dostępu lub kodem autoryzacji (wymienianym później dla tokenu dostępu), w zależności od typu używanego udzielenia autoryzacji.
Udzielanie poświadczeń hasła właściciela zasobu nie powinno być używane z wyjątkiem scenariuszy, w których nie można używać innych przepływów. Jeśli tworzysz SPA, użyj przepływu kodu autoryzacji z PKCE zamiast niejawnego udzielenia.
Serwer autoryzacji
Zgodnie z definicją w strukturze autoryzacji OAuth 2.0 serwer odpowiedzialny za wystawianie tokenów dostępu klientowi po pomyślnym uwierzytelnieniu właściciela zasobu i uzyskaniu autoryzacji. Aplikacja kliencka współdziała z serwerem autoryzacji w czasie wykonywania za pośrednictwem punktów końcowych autoryzacji i tokenu, zgodnie z zdefiniowanymi uprawnieniami autoryzacji protokołu OAuth 2.0.
W przypadku integracji aplikacji Platforma tożsamości Microsoft Platforma tożsamości Microsoft implementuje rolę serwera autoryzacji dla aplikacji Microsoft Entra i interfejsów API usług firmy Microsoft, na przykład interfejsów API programu Microsoft Graph.
Oświadczenie
Oświadczenia to pary nazw/wartości w tokenie zabezpieczającym, które dostarczają asercji wykonanych przez jedną jednostkę do innej. Te jednostki są zazwyczaj aplikacją kliencką lub właścicielem zasobu dostarczającym asercji serwerowi zasobów. Oświadczenia przekazują fakty dotyczące podmiotu tokenu, takiego jak identyfikator podmiotu zabezpieczeń, który został uwierzytelniony przez serwer autoryzacji. Oświadczenia obecne w tokenie mogą się różnić i zależeć od kilku czynników, takich jak typ tokenu, typ poświadczeń używany do uwierzytelniania podmiotu, konfiguracja aplikacji i inne.
Aby uzyskać więcej informacji, zobacz dokumentację tokenu Platforma tożsamości Microsoft.
Aplikacja kliencka
Znany również jako "aktor". Zgodnie z definicją w strukturze autoryzacji OAuth 2.0 aplikacja, która wysyła żądania chronionych zasobów w imieniu właściciela zasobu. Otrzymują uprawnienia od właściciela zasobu w postaci zakresów. Termin "klient" nie oznacza żadnych konkretnych właściwości implementacji sprzętu (na przykład czy aplikacja jest wykonywana na serwerze, na komputerze stacjonarnym lub na innych urządzeniach).
Aplikacja kliencka żąda autoryzacji od właściciela zasobu, aby uczestniczyć w przepływie udzielania autoryzacji OAuth 2.0 i może uzyskiwać dostęp do interfejsów API/danych w imieniu właściciela zasobu. Struktura autoryzacji OAuth 2.0 definiuje dwa typy klientów, "poufne" i "publiczne", na podstawie możliwości zachowania poufności poświadczeń klienta. Aplikacje mogą implementować klienta internetowego (poufnego), który działa na serwerze internetowym, natywnym kliencie (publicznym) zainstalowanym na urządzeniu lub kliencie opartym na agencie użytkownika (publicznym), który działa w przeglądarce urządzenia.
Zgoda
Proces udzielania autoryzacji do aplikacji klienckiej przez właściciela zasobu w celu uzyskania dostępu do chronionych zasobów w ramach określonych uprawnień w imieniu właściciela zasobu. W zależności od uprawnień żądanych przez klienta administrator lub użytkownik zostanie poproszony o zgodę, aby zezwolić na dostęp do ich organizacji/poszczególnych danych odpowiednio. Należy pamiętać, że w scenariuszu z wieloma dzierżawami jednostka usługi aplikacji jest również rejestrowana w dzierżawie użytkownika wyrażającego zgodę.
Aby uzyskać więcej informacji, zobacz platformę wyrażania zgody.
Token identyfikatora
Token zabezpieczający OpenID Connect dostarczony przez punkt końcowy autoryzacji serwera autoryzacji, który zawiera oświadczenia odnoszące się do uwierzytelniania właściciela zasobu użytkownika końcowego. Podobnie jak token dostępu, tokeny identyfikatorów są również reprezentowane jako token internetowy JSON (JWT) podpisany cyfrowo. W przeciwieństwie do tokenu dostępu oświadczenia tokenu identyfikatora nie są jednak używane do celów związanych z dostępem do zasobów i kontrolą dostępu.
Aby uzyskać więcej informacji, zobacz dokumentację tokenu identyfikatora.
Tożsamości zarządzane
Eliminuje potrzebę zarządzania poświadczeniami przez deweloperów. Tożsamości zarządzane zapewniają tożsamość aplikacji do użycia podczas nawiązywania połączenia z zasobami obsługującymi uwierzytelnianie firmy Microsoft Entra. Aplikacje mogą używać tożsamości zarządzanej do uzyskiwania Platforma tożsamości Microsoft tokenów. Na przykład aplikacja może używać tożsamości zarządzanej do uzyskiwania dostępu do zasobów, takich jak usługa Azure Key Vault, gdzie deweloperzy mogą przechowywać poświadczenia w bezpieczny sposób lub uzyskiwać dostęp do kont magazynu. Aby uzyskać więcej informacji, zobacz Omówienie tożsamości zarządzanych.
Platforma tożsamości firmy Microsoft
Platforma tożsamości Microsoft to ewolucja platformy tożsamości Firmy Microsoft Entra i platformy deweloperów. Dzięki niej deweloperzy mogą tworzyć aplikacje, które logują użytkowników przy użyciu wszystkich tożsamości firmy Microsoft i uzyskują tokeny do wywoływania programu Microsoft Graph, innych interfejsów API firmy Microsoft lub interfejsów API opracowanych przez deweloperów. Jest to w pełni funkcjonalna platforma, która składa się z usługi uwierzytelniania, bibliotek, rejestracji aplikacji i konfiguracji, pełnej dokumentacji deweloperów, przykładów kodu i innej zawartości dewelopera. Platforma tożsamości firmy Microsoft obsługuje standardowe protokoły branżowe, takie jak OAuth 2.0 i OpenID Connect.
Aplikacja wielodostępna
Klasa aplikacji, która umożliwia logowanie się i wyrażanie zgody przez użytkowników aprowizowania w dowolnej dzierżawie firmy Microsoft Entra, w tym dzierżawy innych niż ta, w której klient jest zarejestrowany. Aplikacje klienckie natywne są domyślnie wielodostępne, natomiast aplikacje internetowego klienta i zasobu internetowego/interfejsu API mają możliwość wyboru między jedną lub wielodostępną. Z kolei aplikacja internetowa zarejestrowana jako pojedyncza dzierżawa zezwala na logowanie tylko z kont użytkowników aprowizowania w tej samej dzierżawie co ta, w której zarejestrowano aplikację.
Aby uzyskać więcej szczegółów, zobacz Jak zalogować dowolnego użytkownika firmy Microsoft Entra przy użyciu wzorca aplikacji wielodostępnej.
Natywny klient
Typ aplikacji klienckiej instalowanej natywnie na urządzeniu. Ponieważ cały kod jest wykonywany na urządzeniu, jest uważany za "publicznego" klienta ze względu na brak możliwości przechowywania poświadczeń prywatnie/poufnych. Aby uzyskać więcej informacji, zobacz Typy klientów i profile protokołu OAuth 2.0.
Uprawnienia
Aplikacja kliencka uzyskuje dostęp do serwera zasobów, deklarując żądania uprawnień. Dostępne są dwa typy:
- Uprawnienia delegowane, które określają dostęp oparty na zakresie przy użyciu autoryzacji delegowanej od zalogowanego właściciela zasobu, są prezentowane zasobowi w czasie wykonywania jako oświadczenia "scp" w tokenie dostępu klienta. Wskazują one uprawnienie przyznane aktorowi przez podmiot.
- Uprawnienia "Aplikacja", które określają dostęp oparty na rolach przy użyciu poświadczeń/tożsamości aplikacji klienckiej, są prezentowane zasobowi w czasie wykonywania jako oświadczenia "role" w tokenie dostępu klienta. Wskazują one uprawnienia przyznane podmiotowi przez dzierżawę.
Są one również widoczne podczas procesu wyrażania zgody , dając administratorowi lub właścicielowi zasobu możliwość udzielenia/odmowy dostępu klienta do zasobów w dzierżawie.
Żądania uprawnień są konfigurowane na stronie uprawnień interfejsu API dla aplikacji, wybierając żądane "Delegowane uprawnienia" i "Uprawnienia aplikacji" (ta ostatnia wymaga członkostwa w roli administratora globalnego). Ponieważ klient publiczny nie może bezpiecznie obsługiwać poświadczeń, może żądać tylko delegowanych uprawnień, podczas gdy poufny klient ma możliwość żądania uprawnień delegowanych i uprawnień aplikacji. Obiekt aplikacji klienta przechowuje zadeklarowane uprawnienia we właściwości requiredResourceAccess.
Odświeżanie tokenu
Typ tokenu zabezpieczającego wystawionego przez serwer autoryzacji. Przed wygaśnięciem tokenu dostępu aplikacja kliencka dołącza skojarzony token odświeżania, gdy żąda nowego tokenu dostępu z serwera autoryzacji. Tokeny odświeżania są zwykle formatowane jako token internetowy JSON (JWT).
W przeciwieństwie do tokenów dostępu można odwołać tokeny odświeżania. Serwer autoryzacji odrzuca wszelkie żądania z aplikacji klienckiej zawierającej token odświeżania, który został odwołany. Gdy serwer autoryzacji odrzuca żądanie zawierające odwołany token odświeżania, aplikacja kliencka traci uprawnienia dostępu do serwera zasobów w imieniu właściciela zasobu.
Aby uzyskać więcej informacji, zobacz tokeny odświeżania.
Właściciel zasobu
Zgodnie z definicją w strukturze autoryzacji OAuth 2.0 jednostka, która może udzielić dostępu do chronionego zasobu. Gdy właściciel zasobu jest osobą, jest określany jako użytkownik końcowy. Na przykład gdy aplikacja kliencka chce uzyskać dostęp do skrzynki pocztowej użytkownika za pośrednictwem interfejsu API programu Microsoft Graph, wymaga uprawnień od właściciela zasobu skrzynki pocztowej. "Właściciel zasobu" jest również czasami nazywany tematem.
Każdy token zabezpieczający reprezentuje właściciela zasobu. Właściciel zasobu jest tym, co reprezentuje oświadczenie podmiotu, oświadczenie o identyfikatorze obiektu i dane osobowe w tokenie. Właściciele zasobów to strona, która udziela delegowanych uprawnień do aplikacji klienckiej w postaci zakresów. Właściciele zasobów są również adresatami ról , którzy wskazują rozszerzone uprawnienia w dzierżawie lub w aplikacji.
Serwer zasobów
Zgodnie z definicją w strukturze autoryzacji OAuth 2.0 serwer hostujący chronione zasoby, który może akceptować chronione żądania zasobów i odpowiadać na nie przez aplikacje klienckie, które prezentują token dostępu. Znany również jako chroniony serwer zasobów lub aplikacja zasobów.
Serwer zasobów uwidacznia interfejsy API i wymusza dostęp do chronionych zasobów za pośrednictwem zakresów i ról przy użyciu struktury autoryzacji OAuth 2.0. Przykłady obejmują interfejs API programu Microsoft Graph, który zapewnia dostęp do danych dzierżawy firmy Microsoft Entra oraz interfejsy API platformy Microsoft 365, które zapewniają dostęp do danych, takich jak poczta i kalendarz.
Podobnie jak aplikacja kliencka, konfiguracja tożsamości aplikacji zasobów jest ustanawiana za pośrednictwem rejestracji w dzierżawie firmy Microsoft Entra, zapewniając zarówno obiekt aplikacji, jak i jednostki usługi. Niektóre interfejsy API udostępniane przez firmę Microsoft, takie jak interfejs API programu Microsoft Graph, mają wstępnie zarejestrowane jednostki usługi udostępnione we wszystkich dzierżawach podczas aprowizacji.
Role
Podobnie jak w przypadku zakresów, role aplikacji umożliwiają serwerowi zasobów zarządzanie dostępem do chronionych zasobów. W przeciwieństwie do zakresów role reprezentują uprawnienia, które podmiot otrzymał poza punktem odniesienia — dlatego czytanie własnej wiadomości e-mail jest zakresem, a jednocześnie administrator poczty e-mail, który może odczytywać wiadomości e-mail wszystkich użytkowników, jest rolą.
Role aplikacji mogą obsługiwać dwa typy przypisań: przypisanie "użytkownika" implementuje kontrolę dostępu opartą na rolach dla użytkowników/grup, które wymagają dostępu do zasobu, podczas gdy przypisanie "aplikacja" implementuje to samo dla aplikacji klienckich , które wymagają dostępu. Rolę aplikacji można zdefiniować jako przypisaną przez użytkownika, przypisaną przez aplikacjębnle lub obie te elementy.
Role to ciągi zdefiniowane przez zasób (na przykład "Osoba zatwierdzająca wydatki", "Tylko do odczytu", "Directory.ReadWrite.All"), zarządzane za pośrednictwem manifestu aplikacji zasobu i przechowywane we właściwości appRoles zasobu. Użytkownicy mogą być przypisywani do ról przypisanych przez użytkownika, a uprawnienia aplikacji klienckiej można skonfigurować tak, aby żądać ról przypisywanych przez aplikację.
Szczegółowe omówienie ról aplikacji udostępnianych przez interfejs API programu Microsoft Graph można znaleźć w temacie Graph API Permission Scopes (Zakresy uprawnień interfejsu API programu Graph). Aby zapoznać się z przykładem implementacji krok po kroku, zobacz Dodawanie lub usuwanie przypisań ról platformy Azure.
Zakresy
Podobnie jak role, zakresy umożliwiają serwerowi zasobów zarządzanie dostępem do chronionych zasobów. Zakresy służą do implementowania kontroli dostępu opartej na zakresie dla aplikacji klienckiej, która otrzymała delegowany dostęp do zasobu przez jego właściciela.
Zakresy to ciągi zdefiniowane przez zasób (na przykład "Mail.Read", "Directory.ReadWrite.All"), zarządzane za pośrednictwem manifestu aplikacji zasobu i przechowywane we właściwości oauth2Permissions zasobu. Delegowane uprawnienia aplikacji klienckiej można skonfigurować w celu uzyskania dostępu do zakresu.
Najlepszą konwencją nazewnictwa jest użycie formatu "resource.operation.constraint". Szczegółowe omówienie zakresów uwidocznionych przez interfejs API programu Microsoft Graph można znaleźć w temacie Graph API Permission Scopes (Zakresy uprawnień interfejsu API programu Graph). Aby uzyskać zakresy uwidocznione przez usługi Microsoft 365, zobacz Dokumentacja uprawnień interfejsu API platformy Microsoft 365.
Token zabezpieczający
Podpisany dokument zawierający oświadczenia, takie jak token OAuth 2.0 lub aseracja SAML 2.0. W przypadku udzielenia autoryzacji protokołu OAuth 2.0 token dostępu (OAuth2), token odświeżania i token identyfikatora są typami tokenów zabezpieczających, z których wszystkie są implementowane jako token internetowy JSON (JWT).
Obiekt jednostki usługi
Podczas rejestrowania/aktualizowania aplikacji zarówno obiekt aplikacji, jak i odpowiedni obiekt jednostki usługi są tworzone/aktualizowane dla tej dzierżawy. Obiekt aplikacji definiuje konfigurację tożsamości aplikacji globalnie (we wszystkich dzierżawach, w których udzielono dostępu skojarzonej aplikacji) i jest szablonem, z którego pochodzą odpowiednie obiekty jednostki usługi do użytku lokalnego w czasie wykonywania (w określonej dzierżawie).
Aby uzyskać więcej informacji, zobacz Application and Service Principal Objects (Obiekty aplikacji i jednostki usługi).
Logowanie
Proces aplikacji klienckiej inicjującej uwierzytelnianie użytkownika końcowego i przechwytywanie powiązanego stanu żądania tokenu zabezpieczającego i określania zakresu sesji aplikacji do tego stanu. Stan może zawierać artefakty, takie jak informacje o profilu użytkownika, oraz informacje pochodzące z oświadczeń tokenu.
Funkcja logowania aplikacji jest zwykle używana do implementowania logowania jednokrotnego. Może być również poprzedzona funkcją "rejestracja" jako punkt wejścia dla użytkownika końcowego w celu uzyskania dostępu do aplikacji (po pierwszym logowaniu). Funkcja rejestracji służy do zbierania i utrwalania dodatkowego stanu specyficznego dla użytkownika i może wymagać zgody użytkownika.
Wylogowywanie
Proces nieuwierzytelniania użytkownika końcowego, odłączania stanu użytkownika skojarzonego z sesją aplikacji klienckiej podczas logowania
Temat
Znany również jako właściciel zasobu.
Dzierżawa
Wystąpienie katalogu Microsoft Entra jest nazywane dzierżawą firmy Microsoft Entra. Udostępnia kilka funkcji, w tym:
- usługa rejestru dla zintegrowanych aplikacji
- uwierzytelnianie kont użytkowników i zarejestrowanych aplikacji
- Punkty końcowe REST wymagane do obsługi różnych protokołów, w tym protokołu OAuth 2.0 i SAML, w tym punktu końcowego autoryzacji, punktu końcowego tokenu i "wspólnego" punktu końcowego używanego przez aplikacje wielodostępne.
Dzierżawy firmy Microsoft Entra są tworzone/skojarzone z subskrypcjami platformy Azure i platformy Microsoft 365 podczas rejestracji, zapewniając funkcje zarządzania tożsamościami i dostępem dla subskrypcji. Administratorzy subskrypcji platformy Azure mogą również tworzyć dodatkowe dzierżawy firmy Microsoft Entra. Zobacz Jak uzyskać dzierżawę firmy Microsoft Entra, aby uzyskać szczegółowe informacje na temat różnych sposobów uzyskiwania dostępu do dzierżawy. Aby uzyskać szczegółowe informacje na temat relacji między subskrypcjami i dzierżawą firmy Microsoft Entra, zobacz Kojarzenie lub dodawanie subskrypcji platformy Azure do dzierżawy entra firmy Microsoft oraz instrukcje dotyczące sposobu kojarzenia lub dodawania subskrypcji do dzierżawy firmy Microsoft Entra.
Punkt końcowy tokenu
Jeden z punktów końcowych zaimplementowanych przez serwer autoryzacji do obsługi udzielania autoryzacji protokołu OAuth 2.0. W zależności od udzielenia może służyć do uzyskiwania tokenu dostępu (i powiązanego tokenu "odświeżania") do klienta lub tokenu identyfikatora w przypadku użycia z protokołem OpenID Connect.
Klient oparty na agencie użytkownika
Typ aplikacji klienckiej pobierającej kod z serwera internetowego i wykonywany w ramach agenta użytkownika (na przykład przeglądarki internetowej), takiego jak jednostronicowa aplikacja (SPA). Ponieważ cały kod jest wykonywany na urządzeniu, jest uważany za "publicznego" klienta ze względu na brak możliwości przechowywania poświadczeń prywatnie/poufnych. Aby uzyskać więcej informacji, zobacz OAuth 2.0 client types and profiles (Typy i profile klientów OAuth 2.0).
Podmiot zabezpieczeń użytkownika
Podobnie jak w przypadku obiektu jednostki usługi do reprezentowania wystąpienia aplikacji, obiekt główny użytkownika jest innym typem podmiotu zabezpieczeń, który reprezentuje użytkownika. Typ zasobu programu Microsoft Graph User definiuje schemat dla obiektu użytkownika, w tym właściwości związane z użytkownikiem, takie jak imię i nazwisko, główna nazwa użytkownika, członkostwo w roli katalogu itd. Zapewnia to konfigurację tożsamości użytkownika dla identyfikatora Entra firmy Microsoft w celu ustanowienia podmiotu zabezpieczeń użytkownika w czasie wykonywania. Jednostka użytkownika służy do reprezentowania uwierzytelnionego użytkownika na potrzeby logowania jednokrotnego, rejestrowania delegowania zgody , podejmowania decyzji dotyczących kontroli dostępu itd.
Klient sieci Web
Typ aplikacji klienckiej, która wykonuje cały kod na serwerze internetowym, działając jako poufny klient, ponieważ może bezpiecznie przechowywać swoje poświadczenia na serwerze. Aby uzyskać więcej informacji, zobacz OAuth 2.0 client types and profiles (Typy i profile klientów OAuth 2.0).
Tożsamość obciążenia
Tożsamość używana przez obciążenie oprogramowania, takie jak aplikacja, usługa, skrypt lub kontener do uwierzytelniania i uzyskiwania dostępu do innych usług i zasobów. W usłudze Microsoft Entra ID tożsamości obciążeń to aplikacje, jednostki usługi i tożsamości zarządzane. Aby uzyskać więcej informacji, zobacz Omówienie tożsamości obciążenia.
Federacja tożsamości obciążenia
Umożliwia bezpieczny dostęp do chronionych zasobów firmy Microsoft przed zewnętrznymi aplikacjami i usługami bez konieczności zarządzania wpisami tajnymi (w przypadku obsługiwanych scenariuszy). Aby uzyskać więcej informacji, zobacz Federacja tożsamości obciążenia.
Następne kroki
Wiele terminów w tym słowniku jest powiązanych z protokołami OAuth 2.0 i OpenID Connect. Chociaż nie musisz wiedzieć, jak protokoły działają "na drutach", aby korzystać z platformy tożsamości, znajomość niektórych podstaw protokołu może ułatwić tworzenie i debugowanie uwierzytelniania i autoryzacji w aplikacjach: