Glosář: Microsoft identity platform

Tyto podmínky se zobrazí při používání naší dokumentace, Azure Portal, knihoven ověřování a Graph API Microsoftu. Některé termíny jsou specifické pro Microsoft, zatímco jiné souvisejí s protokoly, jako je OAuth nebo jiné technologie, které používáte s Microsoft identity platform.

Přístupový token

Typ tokenu zabezpečení vydaného autorizačním serverem a používaného klientskou aplikací pro přístup k chráněnému serveru prostředků. Token obvykle ve formě webového tokenu JSON (JWT) ztělesňuje autorizaci udělenou klientovi vlastníkem prostředku pro požadovanou úroveň přístupu. Token obsahuje všechny použitelné deklarace identity týkající se předmětu a umožňuje klientské aplikaci používat ho 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é pouze po krátkou dobu a nelze je odvolat. Autorizační server může při vydání přístupového tokenu vydat obnovovací token. Obnovovací tokeny jsou obvykle poskytovány pouze důvěrným klientským aplikacím.

Přístupové tokeny se někdy označují jako "uživatel+ aplikace" nebo "jenom aplikace" v závislosti na přihlašovacích údajích, které jsou reprezentované. Například když klientská aplikace používá:

  • Autorizační kód udělí, koncový uživatel se nejprve ověří jako vlastník prostředku a deleguje autorizaci klientovi pro přístup k prostředku. Klient se následně ověří při získání přístupového tokenu. Token může být někdy označován konkrétněji jako token uživatel+aplikace, 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í, které funguje bez ověřování/autorizace vlastníka prostředku, takže token může být někdy označován jako token jen pro aplikaci.

Další podrobnosti najdete v referenčních informacích o přístupových tokenech .

Aktér

Jiný termín pro klientskou aplikaci. Aktér je strana jednající jménem subjektu (vlastníka prostředku).

ID aplikace (klienta)

ID aplikace neboli ID klienta je hodnota, kterou Microsoft identity platform přiřadí aplikaci, když ji zaregistrujete v Azure AD. ID aplikace je hodnota guid, která jednoznačně identifikuje aplikaci a její konfiguraci v rámci platformy Identity. ID aplikace přidáte do kódu vaší aplikace a knihovny ověřování zahrnou hodnotu ve svých požadavcích na platformu Identity Platform za běhu aplikace. ID aplikace (klienta) není tajný kód – nepoužívejte ho jako heslo nebo jiné přihlašovací údaje.

Manifest aplikace

Funkce poskytovaná Azure Portal, která vytváří reprezentaci JSON konfigurace identity aplikace, která slouží jako mechanismus pro aktualizaci přidružených entit Application a ServicePrincipal. Další podrobnosti najdete v tématu Vysvětlení manifestu aplikace Azure Active Directory .

Objekt aplikace

Když zaregistrujete nebo aktualizujete aplikaci v Azure Portal, portál vytvoří nebo aktualizuje objekt aplikace i odpovídající instanční objekt pro daného tenanta. 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í instanční objekty pro místní použití za běhu (v konkrétním tenantovi).

Další informace najdete v tématu Objekty aplikace a instanční objekty.

Registrace aplikací

Aby se aplikace mohla integrovat s funkcemi správy identit a přístupu a delegovat je na Azure AD, musí být zaregistrovaná v tenantovi Azure AD. Když zaregistrujete aplikaci v Azure AD, poskytujete konfiguraci identity pro aplikaci, která umožňuje její integraci s Azure AD a používání funkcí, jako jsou:

Další podrobnosti najdete v tématu Integrace aplikací s Azure Active Directory .

Authentication

Výzva straně k získání legitimních přihlašovacích údajů a poskytnutí základu pro vytvoření objektu zabezpečení, který se má použít pro řízení identity a přístupu. Například během udělení autorizace OAuth 2.0 ověřovací strana plní roli vlastníka prostředku nebo klientské aplikace v závislosti na použitém udělení.

Autorizace

Jedná se o udělení oprávnění k nějaké akci ověřenému objektu zabezpečení. V modelu programování Azure AD existují dva hlavní případy použití:

Autorizační kód

Krátkodobá hodnota poskytnutá koncovým bodem autorizaceklientské aplikaci během toku udělení autorizačního kódu OAuth 2.0, jedno ze čtyř udělení autorizace OAuth 2.0. Autorizační kód se také označuje jako ověřovací kód a autorizační kód se vrátí klientské aplikaci v reakci na ověření vlastníka prostředku. Ověřovací kód označuje, že vlastník prostředku delegoval oprávnění klientské aplikaci pro přístup k prostředkům. V rámci toku se ověřovací kód později uplatní jako 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 poskytnutí udělení autorizace během toku udělení autorizace OAuth 2.0. V závislosti na použitém toku udělení autorizace se může skutečné poskytnuté udělení lišit, včetně autorizačního kódu nebo tokenu zabezpečení.

Další podrobnosti najdete v částech o typech udělení autorizace a koncovém bodu autorizace ve specifikaci OAuth 2.0 a ve specifikaci OpenIDConnect .

Udělení autorizace

Přihlašovací údaje představující autorizacivlastníka prostředku pro přístup k chráněným prostředkům udělené klientské aplikaci. Klientská aplikace může k získání grantu použít jeden ze čtyř typů udělení definovaných autorizační architekturou OAuth 2.0 v závislosti na typu nebo požadavcích klienta: "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 (později vyměněný za přístupový token) v závislosti na použitém typu udělení autorizace.

Autorizační server

Jak definuje autorizační rozhraní 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ů tokenu v souladu s definovanými autorizačními oprávněními OAuth 2.0.

V případě integrace Microsoft identity platform aplikací Microsoft identity platform implementuje roli autorizačního serveru pro Azure AD aplikace a rozhraní API služeb Microsoftu, například rozhraní Microsoft Graph API.

Deklarovat

Deklarace identity jsou dvojice název/hodnoty v tokenu zabezpečení , které poskytují kontrolní výrazy provedené jednou entitou druhé. Těmito entitami jsou obvykle klientská aplikace nebo vlastník prostředku poskytující kontrolní výrazy serveru prostředků. Fakta přenosu deklarací identity týkající se předmětu tokenu, jako je ID objektu zabezpečení ověřeného autorizačním serverem. Deklarace identity v tokenu se mohou lišit a záviset na několika faktorech, jako je typ tokenu, typ přihlašovacích údajů používaných k ověření 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 "aktér". Jak je definováno autorizační architekturou OAuth 2.0, aplikace, která provádí požadavky na chráněné prostředky jménem vlastníka prostředku. Dostanou oprávnění od vlastníka prostředku ve formě oborů. Termín "klient" neznamená žádné konkrétní charakteristiky implementace hardwaru (například jestli se aplikace spouští na serveru, na ploše nebo na jiných zařízeních).

Klientská aplikace požádá vlastníka prostředku o autorizaci , aby se mohl účastnit toku udělení autorizace OAuth 2.0 , a může přistupovat k rozhraním API nebo datům jménem vlastníka prostředku. Autorizační rozhraní 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ého), který běží na webovém serveru, nativního klienta (veřejného) nainstalovaného na zařízení nebo klienta založeného na uživatelském agentovi (veřejném), který běží v prohlížeči zařízení.

Proces , kdy vlastník prostředku uděluje autorizaci klientské aplikaci pro přístup k chráněným prostředkům na základě konkrétních oprávnění 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 k datům organizace nebo k jednotlivý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, který s tím souhlasí.

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

Token ID

Token zabezpečeníOpenID Connect poskytovaný koncovým bodem autorizaceautorizač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é reprezentované 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 související s přístupem k prostředkům a konkrétně s řízením přístupu.

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

Spravované identity

Eliminuje potřebu správy přihlašovacích údajů pro vývojáře. Spravované identity poskytují identitu, kterou mohou aplikace používat při připojování k prostředkům, které podporují ověřování Azure AD. Aplikace můžou spravovanou identitu používat k získání tokenů Azure AD. Aplikace může například používat 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

Microsoft identity platform je vývoj služby identit Azure Active Directory (Azure AD) a vývojářské platformy. Umožňuje vývojářům vytvářet aplikace, které přihlašují všechny identity od Microsoftu a získávají 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.

Aplikace s více tenanty

Třída aplikace, která umožňuje přihlášení a vyjádření souhlasu uživatelům zřízeným v libovolném tenantovi Azure AD, včetně tenantů jiných, než je ten, ve kterém je klient zaregistrovaný. Nativní klientské aplikace jsou ve výchozím nastavení víceklientské, zatímco webové klientské aplikace a webové prostředky nebo aplikace rozhraní API mají možnost výběru mezi jedním nebo více tenanty. Naproti tomu webová aplikace zaregistrovaná jako jeden tenant by umožňovala přihlášení jenom z uživatelských účtů zřízených ve stejném tenantovi, ve kterém je aplikace zaregistrovaná.

Další podrobnosti najdete v tématu Přihlášení libovolného uživatele Azure AD pomocí vzoru aplikace s více tenanty.

Nativní klient

Typ klientské aplikace , která se na zařízení instaluje nativně. Vzhledem k tomu, že se veškerý kód spouští na zařízení, považuje se za "veřejného" klienta, protože není možné 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ů deklarováním žádostí o oprávnění. K dispozici jsou dva typy:

Zobrazí se také během procesu udělení souhlasu a dává 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.

Požadavky na oprávnění se konfigurují na stránce oprávnění rozhraní API pro aplikaci v Azure Portal výběrem požadovaných "Delegovaná oprávnění" a "Oprávnění aplikace" (druhá možnost vyžaduje členství v roli globálního správce). Vzhledem k tomu, ž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ůže požadovat delegovaná oprávnění i oprávnění aplikace. Objekt aplikace klienta ukládá deklarovaná oprávnění ve své vlastnosti requiredResourceAccess.

Obnovovací token

Typ tokenu zabezpečení vydaného autorizačním serverem. Před vypršením platnosti přístupového tokenu klientská aplikace při žádosti o nový přístupový token z autorizačního serveru zahrne přidružený obnovovací token . Obnovovací tokeny jsou obvykle formátované jako JSON Web Token (JWT).

Na rozdíl od přístupových tokenů je možné obnovovací tokeny odvolat. Autorizační server odmítne všechny požadavky z klientské aplikace, které obsahují obnovovací token, který byl odvolán. Když autorizační server odmítne požadavek, 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

Podle definice autorizačního rozhraní OAuth 2.0 je entita schopná 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. Když například klientská aplikace chce získat přístup k poštovní schránce uživatele prostřednictvím Graph API Microsoft, vyžaduje oprávnění od 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íkem prostředku je to, co představuje deklarace subjektu, ID objektu a osobní údaje v tokenu. Vlastníci prostředků jsou strana, 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 definuje autorizační rozhraní OAuth 2.0, server, který je hostitelem chráněných prostředků, schopný přijímat a reagovat na žádosti o chráněné prostředky klientskými aplikacemi , které poskytují přístupový token. Označuje se také jako server chráněných 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ří microsoft Graph API, který poskytuje přístup k datům Azure AD tenantů, a rozhraní API Microsoftu 365, která poskytují přístup k datům, jako je pošta a kalendář.

Stejně jako u klientské aplikace se konfigurace identity aplikace prostředků vytváří prostřednictvím registrace v tenantovi Azure AD, který poskytuje jak aplikaci, tak instanční objekt. Některá rozhraní API poskytovaná Microsoftem, například Microsoft Graph API, mají během zřizování ve všech tenantech k dispozici předem zaregistrované instanční objekty.

Role

Aplikační role podobně jako obory poskytují serveru prostředků způsob, jak řídit přístup k chráněným prostředkům. Na rozdíl od rozsahů role představují oprávnění, která byla předmětu udělena nad rámec směrného plánu . To je důvod, proč je čtení vlastních e-mailů obor, zatímco role správce e-mailu, který může číst e-maily všech uživatelů, je role.

Aplikační role 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. Aplikační roli je možné definovat jako přiřazení uživatelem, přiřazení aplikace nebo obojí.

Role jsou řetězce definované prostředkem (například schvalovatel výdajů, jen pro čtení, Directory.ReadWrite.All), spravované v Azure Portal prostřednictvím manifestu aplikace prostředku a uložené ve vlastnosti appRoles prostředku. Azure Portal slouží také k přiřazování uživatelů k přiřaditelným rolím uživatelů a konfiguraci oprávnění klientské aplikace tak, aby vyžadovala přiřaditelné role aplikace.

Podrobný popis aplikačních rolí vystavených službou Microsoft Graph API najdete v tématu rozsahy oprávnění Graph API. Podrobný příklad implementace najdete v tématu Přidání nebo odebrání přiřazení rolí Azure pomocí Azure Portal.

Obory

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é vlastník udělil delegovaný přístup k prostředku.

Obory jsou řetězce definované prostředkem (například Mail.Read, Directory.ReadWrite.All), spravované v Azure Portal prostřednictvím manifestu aplikace prostředku a uložené ve vlastnosti oauth2Permissions prostředku. Azure Portal slouží také ke konfiguraci delegovaných oprávnění klientské aplikace pro přístup k oboru.

Osvědčeným postupem pro vytváření názvů je použití formátu resource.operation.constraint. Podrobný popis oborů vystavených Microsoftem Graph API najdete v tématu Graph API rozsahy oprávnění. Obory zveřejněné 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. V případě udělení autorizace OAuth 2.0 jsou typy tokenů zabezpečení přístupový token (OAuth2), obnovovací token a token ID, které se implementují jako webový token JSON (JWT).

Instanční objekt

Když zaregistrujete nebo aktualizujete aplikaci v Azure Portal, portál vytvoří nebo aktualizuje objekt aplikace i odpovídající instanční objekt pro daného tenanta. Objekt aplikace definuje konfiguraci identity aplikace globálně (napříč všemi tenanty, kde má přidružená aplikace udělený přístup) a je to šablona, ze které se odvozují odpovídající instanční objekty pro místní použití za běhu (v konkrétním tenantovi).

Další informace najdete v tématu Objekty aplikace a instanční objekty.

Přihlášení

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

Funkce přihlašování aplikace se obvykle používá k implementaci jednotného přihlašování (SSO). Může jí také předcházet funkce "registrace", která je vstupním bodem pro koncového uživatele k získání přístupu k aplikaci (při prvním přihlášení). Registrační funkce slouží ke shromažďování a uchovávání dalších stavů specifických 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 Azure AD se označuje jako tenant Azure AD. Poskytuje několik funkcí, mezi které patří:

Azure AD tenanti se vytvářejí nebo přidružují k předplatným Azure a Microsoft 365 a poskytují identitu & Funkce správy přístupu pro předplatné. Správci předplatného Azure mohou také vytvářet další tenanty Azure AD prostřednictvím Azure Portal. Podrobnosti o různých způsobech získání přístupu k tenantovi najdete v tématu Jak získat tenanta Azure Active Directory . Podrobnosti o vztahu mezi předplatnými a tenantem Azure AD a pokyny k přidružení nebo přidání předplatného Azure k tenantovi Azure AD najdete v tématu Přidružení nebo přidání předplatného Azure do tenanta Azure Active Directory.

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í se dá použít k získání přístupového tokenu (a souvisejícího "obnovovacího" tokenu) pro klienta nebo tokenu ID při použití s protokolem OpenID Connect .

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

Typ klientské aplikace , která stahuje kód z webového serveru a spouští se v rámci uživatelského agenta (například webového prohlížeče), jako je jednostránková aplikace (SPA). Vzhledem k tomu, že se veškerý kód spouští na zařízení, považuje se za "veřejného" klienta, protože není možné 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 instanční objekt se používá k reprezentaci instance aplikace, je objekt zabezpečení uživatele dalším typem objektu zabezpečení, který představuje uživatele. Typ prostředku Uživatel Microsoft Graphu 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 Azure AD k vytvoření objektu zabezpečení uživatele za běhu. Objekt zabezpečení uživatele slouží k reprezentaci ověřeného uživatele pro jednotné přihlašování, záznam 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 a 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 úlohy

Identita používaná softwarovými úlohami, 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 Azure AD jsou identitami úloh aplikace, instanční objekty a spravované identity. Další informace najdete v tématu Přehled identit úloh.

Federace identit úloh

Umožňuje zabezpečený přístup k Azure AD chráněným prostředkům z externích aplikací a služeb, aniž byste museli 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átě", abyste mohli používat platformu Identity, znalost některých základních informací o protokolech vám může pomoct snadněji vytvářet a ladit ověřování a autorizaci ve vašich aplikacích: