Sdílet prostřednictvím

Glosář: Microsoft Identity Platform

  • Článek

Tyto termíny se zobrazí, když používáte naši dokumentaci, centrum pro správu Microsoft Entra, knihovny ověřování a rozhraní Microsoft Graph API. Některé termíny jsou specifické pro Microsoft, zatímco jiné souvisí s protokoly, jako je OAuth nebo jiné technologie, které používáte s platformou Microsoft Identity Platform.

Token přístupu

Typ tokenu zabezpečení vystaveného autorizačním serverem a používaný klientskou aplikací pro přístup k chráněnému serveru prostředků. Obvykle ve formě webového tokenu JSON (JWT) token představuje autorizaci udělenou klientovi vlastníkem prostředku pro požadovanou úroveň přístupu. Token obsahuje všechny příslušné deklarace identity týkající se předmětu, což klientské aplikaci umožňuje jeho použití jako formu přihlašovacích údajů při přístupu k danému prostředku. Tím se také eliminuje potřeba, aby vlastník prostředku zpřístupnil přihlašovací údaje klientovi.

Přístupové tokeny jsou platné jenom na krátkou dobu a nelze je odvolat. Autorizační server může také vydat obnovovací token při vydání přístupového tokenu. Obnovovací tokeny jsou obvykle poskytovány pouze důvěrným klientským aplikacím.

Přístupové tokeny se někdy označují jako User+App nebo App-Only v závislosti na představovaných přihlašovacích údajích. Pokud například klientská aplikace používá:

  • Udělení autorizace autorizačního kódu, koncový uživatel se nejprve ověří jako vlastník prostředku a deleguje autorizaci klientovi pro přístup k prostředku. Klient se pak ověří při získání přístupového tokenu. Token se někdy může konkrétněji označovat jako token User+App, protože představuje uživatele, který autorizoval klientskou aplikaci, i aplikaci.
  • Udělení autorizace "Přihlašovací údaje klienta", klient poskytuje jediné ověřování, funguje bez ověřování a autorizace vlastníka prostředku, takže token se někdy může označovat jako token jen pro aplikaci.

Další podrobnosti najdete v referenčních informacích k přístupovým tokenům.

Actor (Herec/herečka)

Jiný termín pro klientskou aplikaci Aktér je strana působící jménem subjektu (vlastníka zdroje).

ID aplikace (klienta)

ID aplikace nebo ID klienta je hodnota, kterou platforma Microsoft Identity Platform přiřadí vaší aplikaci při registraci v Microsoft Entra ID. ID aplikace je hodnota GUID, která jednoznačně identifikuje aplikaci a její konfiguraci v rámci platformy identit. ID aplikace přidáte do kódu aplikace a knihovny ověřování obsahují hodnotu v jejich požadavcích na platformu Identity Platform za běhu aplikace. ID aplikace (klienta) není tajný kód – nepoužívejte ho jako heslo ani jiné přihlašovací údaje.

Manifest aplikace

Manifest aplikace je funkce, která vytváří reprezentaci JSON konfigurace identity aplikace, která se používá jako mechanismus pro aktualizaci přidružených entit aplikace a ServicePrincipal . Další podrobnosti najdete v tématu Vysvětlení manifestu aplikace Microsoft Entra.

Objekt aplikace

Při registraci nebo aktualizaci aplikace se pro daného tenanta vytvoří nebo aktualizuje objekt aplikace i odpovídající instanční objekt . Objekt aplikace definuje konfiguraci identity aplikace globálně (napříč všemi tenanty, ke kterým má přístup), a poskytuje šablonu, ze které se odvozují odpovídající objekty instančního objektu pro místní použití za běhu (v konkrétním tenantovi).

Další informace naleznete v tématu Aplikace a instanční objekty.

Registrace aplikace

Aby bylo možné aplikaci povolit integraci s funkcemi správy identit a přístupu do Microsoft Entra ID a delegovat je, musí být zaregistrovaná v tenantovi Microsoft Entra. Při registraci aplikace pomocí Microsoft Entra ID poskytujete konfiguraci identity pro vaši aplikaci, což umožňuje integraci s Microsoft Entra ID a používání funkcí, jako jsou:

  • Robustní správa jednotného přihlašování pomocí správy identit Microsoft Entra a implementace protokolu OpenID Connect
  • Zprostředkovaný přístup k chráněným prostředkům klientskými aplikacemi prostřednictvím autorizačního serveru OAuth 2.0
  • Architektura souhlasu pro správu přístupu klientů k chráněným prostředkům na základě autorizace vlastníka prostředku

Další podrobnosti najdete v tématu Integrace aplikací s MICROSOFT Entra ID .

Ověřování

Akt výzvy strany k legitimním přihlašovacím údajům, který poskytuje základ pro vytvoření objektu zabezpečení, který se má použít pro správu identit a přístupu. Během udělení autorizace OAuth 2.0 například osoba, která ověřuje, plní roli vlastníka prostředku nebo klientské aplikace v závislosti na použitém udělení.

Autorizace

Akce udělení oprávnění ověřeného objektu zabezpečení k nějaké akci. V programovacím modelu Microsoft Entra existují dva hlavní případy použití:

  • Během toku udělení autorizace OAuth 2.0: když vlastník prostředku udělí autorizaci klientské aplikaci a umožní klientovi přístup k prostředkům vlastníka prostředku.
  • Během přístupu k prostředkům klienta: jak je implementované serverem prostředků, pomocí hodnot deklarací identity, které jsou přítomné v přístupovém tokenu, proveďte rozhodnutí o řízení přístupu na základě nich.

Autorizační kód

Krátkodobá hodnota poskytnutá koncovým bodem autorizace klientské aplikaci během toku udělení autorizačního kódu OAuth 2.0, jednou ze čtyř udělení autorizace OAuth 2.0. Autorizační kód se také označuje jako ověřovací kód, který se vrátí do klientské aplikace v reakci na ověření vlastníka prostředku. Ověřovací kód označuje, že vlastník prostředku má delegovanou autorizaci klientské aplikaci pro přístup k prostředkům. V rámci toku se ověřovací kód později uplatní pro přístupový token.

Koncový bod autorizace

Jeden z koncových bodů implementovaných autorizačním serverem, který slouží k interakci s vlastníkem prostředku za účelem udělení autorizace během toku udělení autorizace OAuth 2.0. V závislosti na použitém toku udělení autorizace se skutečné udělení může lišit, včetně autorizačního kódu nebo tokenu zabezpečení.

Další podrobnosti najdete v částech o autorizačních grantech specifikace OAuth 2.0 a koncových bodech autorizace a specifikaci OpenIDConnect.

Udělení autorizace

Přihlašovací údaje představující autorizaci vlastníka prostředku pro přístup k chráněným prostředkům udělené klientské aplikaci. Klientská aplikace může použít jeden ze čtyř typů udělení definovaných autorizační architekturou OAuth 2.0 k získání grantu v závislosti na typu klienta a požadavcích: "udělení autorizačního kódu", "udělení přihlašovacích údajů klienta", "implicitní udělení" a "udělení přihlašovacích údajů vlastníka prostředku". Přihlašovací údaje vrácené klientovi jsou buď přístupový token, nebo autorizační kód (vyměněný později pro přístupový token) v závislosti na typu použitého autorizačního udělení.

Udělení přihlašovacích údajů vlastníka prostředku by se nemělo používat s výjimkou scénářů, kdy se nedají použít jiné toky. Pokud vytváříte spa, použijte tok autorizačního kódu s PKCE místo implicitního udělení.

Autorizační server

Jak je definováno autorizační architekturou OAuth 2.0, server zodpovědný za vydávání přístupových tokenů klientovi po úspěšném ověření vlastníka prostředku a získání jeho autorizace. Klientská aplikace komunikuje s autorizačním serverem za běhu prostřednictvím jeho autorizačních koncových bodů a koncových bodů tokenů v souladu s definovanými autorizačními uděleními OAuth 2.0.

V případě integrace aplikace Microsoft Identity Platform implementuje platforma Microsoft Identity Platform roli autorizačního serveru pro aplikace Microsoft Entra a rozhraní API služeb Microsoftu, například rozhraní Microsoft Graph API.

Deklarace identity

Deklarace identity jsou páry názvů a hodnot v tokenu zabezpečení, které poskytují kontrolní výrazy provedené jednou entitou. Tyto entity jsou obvykle klientskou aplikací nebo vlastníkem prostředku, který poskytuje kontrolní výrazy pro server prostředků. Deklarace identity předávají fakta o předmětu tokenu, jako je ID objektu zabezpečení, který byl ověřen autorizačním serverem. Deklarace identity v tokenu se můžou lišit a záviset na několika faktorech, jako je typ tokenu, typ přihlašovacích údajů používaných k ověřování předmětu, konfigurace aplikace a další.

Další podrobnosti najdete v referenčních informacích k tokenu Microsoft Identity Platform.

Klientská aplikace

Označuje se také jako "actor". Jak je definováno autorizační architekturou OAuth 2.0, aplikace, která provádí chráněné požadavky na prostředky jménem vlastníka prostředku. Obdrží oprávnění od vlastníka prostředku ve formě oborů. Pojem "klient" neznamená žádné konkrétní vlastnosti implementace hardwaru (například to, jestli se aplikace spouští na serveru, na stolním počítači nebo na jiných zařízeních).

Klientská aplikace požaduje autorizaci od vlastníka prostředku, aby se účastnila toku udělení autorizace OAuth 2.0 a může přistupovat k rozhraním API a datům jménem vlastníka prostředku. Autorizační architektura OAuth 2.0 definuje dva typy klientů, "důvěrné" a "veřejné", na základě schopnosti klienta udržovat důvěrnost svých přihlašovacích údajů. Aplikace můžou implementovat webového klienta (důvěrné), který běží na webovém serveru, nativním klientovi (veřejném) nainstalovaném na zařízení nebo na klientovi založeném na uživatelském agentovi (veřejném), který běží v prohlížeči zařízení.

Proces vlastníka prostředku, který uděluje autorizaci klientské aplikaci, pro přístup k chráněným prostředkům pod určitými oprávněními jménem vlastníka prostředku. V závislosti na oprávněních požadovaných klientem bude správce nebo uživatel požádáni o souhlas s povolením přístupu ke svým organizacím nebo individuálním datům. Všimněte si, že ve scénáři s více tenanty se instanční objekt aplikace zaznamenává také v tenantovi uživatele s souhlasem.

Další informace najdete v rozhraní pro vyjádření souhlasu.

Token ID

Token zabezpečení OpenID Connect poskytnutý koncovým bodem autorizace autorizačního serveru, který obsahuje deklarace identity týkající se ověřování vlastníka prostředku koncového uživatele. Podobně jako přístupový token jsou tokeny ID také reprezentovány jako digitálně podepsaný webový token JSON (JWT). Na rozdíl od přístupového tokenu se deklarace identity tokenu ID nepoužívají pro účely přístupu k prostředkům a konkrétně řízení přístupu.

Další podrobnosti najdete v referenčních informacích k tokenu ID.

Spravované identity

Eliminujte potřebu vývojářů spravovat přihlašovací údaje. Spravované identity poskytují identitu pro aplikace, které se mají použít při připojování k prostředkům, které podporují ověřování Microsoft Entra. Aplikace můžou spravovanou identitu použít k získání tokenů platformy Microsoft Identity Platform. Aplikace může například použít spravovanou identitu pro přístup k prostředkům, jako je Azure Key Vault, kde můžou vývojáři bezpečně ukládat přihlašovací údaje nebo přistupovat k účtům úložiště. Další informace najdete v přehledu spravovaných identit.

Microsoft identity platform

Platforma Microsoft Identity Platform je vývoj služby Microsoft Entra identity a platformy pro vývojáře. Umožňuje vývojářům vytvářet aplikace, které přihlašují všechny identity od Microsoftu a získají tokeny pro volání Microsoft Graphu, dalších rozhraní API od Microsoftu nebo rozhraní API, která vytvořili vývojáři. Jedná se o plnohodnotnou platformu, která se skládá z ověřovací služby, knihoven, registrace a konfigurace aplikací, úplné dokumentace pro vývojáře, ukázek kódu a dalšího obsahu pro vývojáře. Microsoft Identity Platform podporuje standardní oborové protokoly, jako jsou OAuth 2.0 a OpenID Connect.

Víceklientová aplikace

Třída aplikace, která umožňuje přihlášení a souhlas uživatelů zřízených v libovolném tenantovi Microsoft Entra, včetně tenantů jiných než tenantů, u kterých je klient zaregistrovaný. Nativní klientské aplikace jsou ve výchozím nastavení víceklientské, zatímco webové klienty a webové prostředky nebo aplikace API mají možnost vybírat mezi jedním nebo více tenanty. Webová aplikace zaregistrovaná jako jeden tenant by naopak umožňovala přihlašování jenom z uživatelských účtů zřízených ve stejném tenantovi jako aplikace, ve kterém je aplikace zaregistrovaná.

Další podrobnosti najdete v tématu Postup přihlášení libovolného uživatele Microsoft Entra pomocí vzoru aplikace s více tenanty.

Nativní klient

Typ klientské aplikace , která je nativně nainstalovaná na zařízení. Vzhledem k tomu, že se na zařízení spouští veškerý kód, považuje se za "veřejného" klienta kvůli nemožnosti ukládat přihlašovací údaje soukromě nebo důvěrně. Další podrobnosti najdete v tématu Typy a profily klientů OAuth 2.0.

Oprávnění

Klientská aplikace získá přístup k serveru prostředků deklarací žádostí o oprávnění. K dispozici jsou dva typy:

Zobrazí se také během procesu souhlasu a poskytne správci nebo vlastníkovi prostředku možnost udělit nebo odepřít klientovi přístup k prostředkům ve svém tenantovi.

Žádosti o oprávnění se konfigurují na stránce oprávnění rozhraní API pro aplikaci tak, že vyberou požadovanou delegovaná oprávnění a oprávnění aplikace (druhá možnost vyžaduje členství v roli globálního správce). Protože veřejný klient nemůže bezpečně udržovat přihlašovací údaje, může požadovat pouze delegovaná oprávnění, zatímco důvěrný klient má možnost požadovat delegovaná i aplikační oprávnění. Objekt aplikace klienta ukládá deklarovaná oprávnění v požadované vlastnostiResourceAccess.

Obnovovací token

Typ tokenu zabezpečení vystaveného autorizačním serverem. Před vypršením platnosti přístupového tokenu klientská aplikace zahrne přidružený obnovovací token, když požádá o nový přístupový token z autorizačního serveru. Obnovovací tokeny se obvykle formátují jako webový token JSON (JWT).

Na rozdíl od přístupových tokenů je možné obnovovací tokeny odvolat. Autorizační server odmítne všechny žádosti od klientské aplikace, která obsahuje obnovovací token, který byl odvolán. Když autorizační server odmítne žádost, která obsahuje odvolaný obnovovací token, klientská aplikace ztratí oprávnění pro přístup k serveru prostředků jménem vlastníka prostředku.

Další podrobnosti najdete v obnovovacích tokenech .

Vlastník prostředku

Jak je definováno autorizační architekturou OAuth 2.0, může entita udělit přístup k chráněnému prostředku. Pokud je vlastníkem prostředku osoba, označuje se jako koncový uživatel. Pokud například klientská aplikace chce získat přístup k poštovní schránce uživatele prostřednictvím rozhraní Microsoft Graph API, vyžaduje oprávnění vlastníka prostředku poštovní schránky. "Vlastník prostředku" se také někdy označuje jako předmět.

Každý token zabezpečení představuje vlastníka prostředku. Vlastník prostředku představuje deklaraci subjektu, deklaraci ID objektu a osobní údaje v tokenu. Vlastníci prostředků jsou stranou, která uděluje delegovaná oprávnění klientské aplikaci ve formě oborů. Vlastníci prostředků jsou také příjemci rolí , které označují rozšířená oprávnění v rámci tenanta nebo v aplikaci.

Server prostředků

Jak je definováno autorizační architekturou OAuth 2.0, server, který hostuje chráněné prostředky, dokáže přijímat požadavky na chráněné prostředky klientskými aplikacemi, které prezentují přístupový token a reagují na ně. Označuje se také jako chráněný server prostředků nebo aplikace prostředků.

Server prostředků zveřejňuje rozhraní API a vynucuje přístup k chráněným prostředkům prostřednictvím oborů a rolí pomocí autorizační architektury OAuth 2.0. Mezi příklady patří rozhraní Microsoft Graph API, které poskytuje přístup k datům tenanta Microsoft Entra, a rozhraní API Microsoftu 365, která poskytují přístup k datům, jako je pošta a kalendář.

Stejně jako klientská aplikace se konfigurace identity aplikace prostředků vytváří prostřednictvím registrace v tenantovi Microsoft Entra, který poskytuje aplikaci i instanční objekt. Některá rozhraní API poskytovaná Microsoftem, jako je rozhraní Microsoft Graph API, mají předregistrované instanční objekty dostupné ve všech tenantech během zřizování.

Role

Podobně jako obory poskytují role aplikací způsob , jak může server prostředků řídit přístup k chráněným prostředkům. Na rozdíl od oborů představují role oprávnění, která předmět dostala nad rámec směrného plánu – proto je čtení vlastního e-mailu oborem, zatímco správce e-mailu, který může číst e-maily všech uživatelů, je role.

Role aplikací můžou podporovat dva typy přiřazení: Přiřazení uživatele implementuje řízení přístupu na základě role pro uživatele nebo skupiny, které vyžadují přístup k prostředku, zatímco přiřazení aplikace implementuje totéž pro klientské aplikace , které vyžadují přístup. Roli aplikace je možné definovat jako uživatelem přiřaditelné, app-assignabnle nebo obojí.

Role jsou řetězce definované prostředkem (například "Schvalovatel výdajů", "Jen pro čtení", "Directory.ReadWrite.All"), spravované prostřednictvím manifestu aplikace prostředku a uložené ve vlastnosti appRoles prostředku. Uživatele je možné přiřadit k přiřaditelným rolím uživatele a oprávnění klientské aplikace je možné nakonfigurovat tak, aby požadovaly přiřaditelné role aplikace.

Podrobné informace o rolích aplikací vystavených rozhraním Microsoft Graph API najdete v tématu Obory oprávnění rozhraní Graph API. Podrobný příklad implementace najdete v tématu Přidání nebo odebrání přiřazení rolí Azure.

Rozsahy

Podobně jako role poskytují obory způsob, jak může server prostředků řídit přístup k chráněným prostředkům. Obory se používají k implementaci řízení přístupu na základě oboru pro klientskou aplikaci , která získala delegovaný přístup k prostředku jeho vlastníkem.

Obory jsou řetězce definované prostředky (například Mail.Read, Directory.ReadWrite.All), spravované prostřednictvím manifestu aplikace prostředku a uložené ve vlastnosti oauth2Permissions prostředku. Delegovaná oprávnění klientské aplikace je možné nakonfigurovat pro přístup k oboru.

Osvědčeným postupem je použít formát resource.operation.constraint. Podrobnou diskuzi o oborech vystavených rozhraním Microsoft Graph API najdete v tématu Obory oprávnění rozhraní Graph API. Obory vystavené službami Microsoftu 365 najdete v referenčních informacích k oprávněním rozhraní API Microsoftu 365.

Token zabezpečení

Podepsaný dokument obsahující deklarace identity, jako je token OAuth 2.0 nebo kontrolní výraz SAML 2.0. U udělení autorizace OAuth 2.0 jsou přístupový token (OAuth2), obnovovací token a token ID typy tokenů zabezpečení, z nichž všechny se implementují jako webový token JSON (JWT).

Instanční objekt

Při registraci nebo aktualizaci aplikace se pro daného tenanta vytvoří nebo aktualizuje objekt aplikace i odpovídající instanční objekt. Objekt aplikace definuje globálně konfiguraci identity aplikace (ve všech tenantech, u kterých má přidružená aplikace udělený přístup) a je šablonou, ze které se odvozují odpovídající objekty instančního objektu pro místní použití za běhu (v konkrétním tenantovi).

Další informace naleznete v tématu Aplikace a instanční objekty.

Přihlášení

Proces klientské aplikace iniciující ověřování koncového uživatele a zachycení souvisejícího stavu pro vyžádání tokenu zabezpečení a nastavení rozsahu relace aplikace na tento stav. Stav může zahrnovat artefakty, jako jsou informace o profilu uživatele, a informace odvozené z deklarací identity tokenů.

Přihlašovací funkce aplikace se obvykle používá k implementaci jednotného přihlašování (SSO). Může jí předcházet také funkce registrace, jako vstupní bod pro koncového uživatele, který získá přístup k aplikaci (při prvním přihlášení). Funkce registrace se používá ke shromažďování a zachování dalšího stavu specifického pro uživatele a může vyžadovat souhlas uživatele.

Odhlášení

Proces zrušení ověření koncového uživatele, odpojení stavu uživatele přidruženého k relaci klientské aplikace během přihlašování

Předmět

Označuje se také jako vlastník prostředku.

Tenant

Instance adresáře Microsoft Entra se označuje jako tenant Microsoft Entra. Poskytuje několik funkcí, mezi které patří:

  • služba registru pro integrované aplikace
  • ověřování uživatelských účtů a registrovaných aplikací
  • Koncové body REST potřebné k podpoře různých protokolů, včetně OAuth 2.0 a SAML, včetně autorizačního koncového bodu, koncového bodu tokenu a "společného" koncového bodu používaného víceklientských aplikací.

Tenanti Microsoft Entra se vytvářejí nebo přidružují k předplatným Azure a Microsoftu 365 během registrace a poskytují pro toto předplatné funkce správy identit a přístupu. Správci předplatného Azure můžou také vytvářet další tenanty Microsoft Entra. Podrobnosti o různých způsobech, jak získat přístup k tenantovi Microsoft Entra, najdete v tématu Jak získat přístup k tenantovi. Podrobnosti o vztahu mezi předplatnými a tenantem Microsoft Entra najdete v tématu Přidružení nebo přidání předplatného Azure do tenanta Microsoft Entra a pokyny k přidružení nebo přidání předplatného do tenanta Microsoft Entra.

Koncový bod tokenu

Jeden z koncových bodů implementovaných autorizačním serverem pro podporu udělení autorizace OAuth 2.0. V závislosti na udělení je možné ho použít k získání přístupového tokenu (a souvisejícího tokenu aktualizace) klientovi nebo tokenu ID při použití s protokolem OpenID Connect.

Klient založený na uživatelském agentu

Typ klientské aplikace, která stáhne kód z webového serveru a spustí se v rámci uživatelského agenta (například webového prohlížeče), například jednostránkové aplikace (SPA). Vzhledem k tomu, že se na zařízení spouští veškerý kód, považuje se za "veřejného" klienta kvůli nemožnosti ukládat přihlašovací údaje soukromě nebo důvěrně. Další informace najdete v tématu Typy a profily klientů OAuth 2.0.

Objekt zabezpečení uživatele

Podobně jako se instanční objekt používá k reprezentaci instance aplikace, objekt instančního objektu je dalším typem objektu zabezpečení, který představuje uživatele. Typ prostředku Microsoft Graphu User definuje schéma pro objekt uživatele, včetně vlastností souvisejících s uživatelem, jako je jméno a příjmení, hlavní název uživatele, členství v roli adresáře atd. To poskytuje konfiguraci identity uživatele pro ID Microsoft Entra k vytvoření objektu zabezpečení uživatele za běhu. Instanční objekt uživatele se používá k reprezentaci ověřeného uživatele pro jednotné přihlašování, zaznamenávání delegování souhlasu , rozhodování o řízení přístupu atd.

Webový klient

Typ klientské aplikace , která spouští veškerý kód na webovém serveru, funguje jako důvěrný klient , protože může bezpečně ukládat své přihlašovací údaje na serveru. Další informace najdete v tématu Typy a profily klientů OAuth 2.0.

Identita úloh

Identita používaná softwarovou úlohou, jako je aplikace, služba, skript nebo kontejner k ověřování a přístupu k jiným službám a prostředkům. V Microsoft Entra ID jsou identity úloh aplikace, instanční objekty a spravované identity. Další informace najdete v přehledu identit úloh.

Federace identit úloh

Umožňuje bezpečně přistupovat k prostředkům chráněným Microsoft Entra z externích aplikací a služeb bez nutnosti spravovat tajné kódy (pro podporované scénáře). Další informace najdete v tématu federace identit úloh.

Další kroky

Mnoho termínů v tomto glosáři souvisí s protokoly OAuth 2.0 a OpenID Connect. I když nepotřebujete vědět, jak protokoly fungují "na drátu", abyste mohli používat platformu identity, znalost některých základů protokolu vám může pomoct snadněji sestavovat a ladit ověřování a autorizaci v aplikacích: