Získání autorizace pro přístup k prostředkům

Článek
04/17/2024

Tento článek vám jako vývojář pomůže pochopit, jak nejlépe zajistit nulová důvěra (Zero Trust) při získávání oprávnění pro přístup k prostředkům pro vaši aplikaci. Pro přístup k chráněným prostředkům, jako jsou e-mailová nebo kalendářní data, potřebuje vaše aplikace autorizaci vlastníka prostředku. Vlastník prostředku může souhlasit nebo odepřít žádost vaší aplikace. Vaše aplikace obdrží přístupový token, když vlastník prostředku udělí souhlas; aplikace neobdrží přístupový token, když vlastník prostředku odepře přístup.

Koncepční kontrola

K ověřování a autorizaci aplikací a správě oprávnění a souhlasu můžete použít platformu Microsoft Identity Platform. Začněme některými koncepty:

Ověřování (někdy zkrácené na AuthN) je proces prokázání, že vaše deklarovaná identita je přesná. Platforma Microsoft Identity Platform používá pro zpracování ověřování protokol OpenID Připojení. Autorizace (někdy zkrácená na AuthZ) uděluje ověřené straně oprávnění k něčemu. Určuje, k jakým datům má ověřená strana přístup. Platforma Microsoft Identity Platform používá k zpracování autorizace protokol OAuth2.0 . Mezi možnosti autorizace patří seznamy řízení přístupu (ACL), řízení přístupu na základě role a řízení přístupu atributů (ABAC). Ověřování je často faktorem autorizace.
Pro přístup k datům může vaše aplikace používat delegovaný přístup (jménem přihlášeného uživatele) nebo přímý přístup (funguje jenom jako vlastní identita aplikace). Delegovaný přístup vyžaduje delegovaná oprávnění (označovaná také jako obory), klient a uživatel musí být k provedení žádosti autorizovaný samostatně. Přímý přístup může vyžadovat oprávnění aplikace (označovaná také jako role aplikací), pokud jsou aplikacím uděleny role, dají se volat oprávnění aplikací.
Delegovaná oprávnění používaná s delegovaným přístupem umožňují aplikaci jednat jménem uživatele a přistupovat pouze k tomu, k čemu má uživatel přístup. Oprávnění aplikace, které se používá s přímým přístupem, umožňuje aplikaci přistupovat k datům, ke kterým je oprávnění přidruženo. Oprávnění aplikace můžou udělit jenom správci a vlastníci instančních objektů .
Aplikace obdrží oprávnění prostřednictvím souhlasu. Uživatelé nebo správci autorizuje aplikaci pro přístup k chráněnému prostředku. Výzva k vyjádření souhlasu obsahuje oprávnění, která aplikace vyžaduje, spolu s informacemi o vydavateli.
Vlastníci aplikací prostředků můžou předem autorizovat klientské aplikace (na webu Azure Portal nebo pomocí PowerShellu a rozhraní API, jako je Microsoft Graph). Můžou udělit oprávnění k prostředkům, aniž by uživatelé museli zobrazit výzvu k vyjádření souhlasu pro sadu oprávnění, která byla předem autorizována.

Rozdíl mezi delegovanými oprávněními a oprávněními aplikace

Aplikace fungují ve dvou režimech: když je uživatel přítomný (delegovaná oprávnění) a když neexistuje žádný uživatel (oprávnění aplikace). Když je před aplikací uživatel, budete muset jednat jménem tohoto uživatele; neměli byste jednat jménem samotné aplikace. Když uživatel nasměruje vaši aplikaci, chováte se jako delegát daného uživatele. Získáváte oprávnění jednat jménem uživatele, který token identifikuje.

Aplikace typu služby (úlohy na pozadí, démony, procesy mezi servery) nemají uživatele, kteří se můžou sami identifikovat nebo zadávat heslo. Vyžadují oprávnění aplikace, aby jednala jménem sebe sama (jménem aplikace služby).

osvědčené postupy autorizace aplikací nulová důvěra (Zero Trust)

Přístup k autorizaci bude mít ověřování jako součást, když se připojíte k uživateli, který je k aplikaci přítomný, a k prostředku, který voláte. Když vaše aplikace působí jménem uživatele, nedůvěřujeme volající aplikaci, abychom nám řekli, kdo je, nebo nechat aplikaci rozhodnout, kdo je. ID Microsoft Entra ověří a přímo poskytne informace o uživateli v tokenu.

Pokud potřebujete aplikaci povolit volání rozhraní API nebo autorizaci aplikace tak, aby mohla přistupovat k prostředku, můžou moderní schémata autorizace vyžadovat autorizaci prostřednictvím architektury oprávnění a souhlasu. Referenční postupy zabezpečení pro vlastnosti aplikace, které zahrnují identifikátor URI přesměrování, přístupové tokeny (používané pro implicitní toky), certifikáty a tajné kódy, identifikátor URI ID aplikace a vlastnictví aplikace.

Další kroky

Přizpůsobení tokenů popisuje informace, které můžete získat v tokenech Microsoft Entra a jak přizpůsobit tokeny, aby se zlepšila flexibilita a řízení a současně se zvyšuje zabezpečení nulové důvěryhodnosti aplikace s nejnižšími oprávněními.
Při konfiguraci skupinových deklarací identity a rolí aplikací v tokenech se dozvíte, jak nakonfigurovat aplikace s definicemi rolí aplikací a přiřadit skupiny zabezpečení k rolím aplikací, aby se zlepšila flexibilita a řízení a současně se zvýšilo zabezpečení nulové důvěryhodnosti aplikace s nejnižšími oprávněními.
Vývoj strategie delegovaných oprávnění vám pomůže implementovat nejlepší přístup ke správě oprávnění v aplikaci a vyvíjet pomocí principů nulová důvěra (Zero Trust).
Vývoj strategie oprávnění aplikací vám pomůže při rozhodování o přístupu k oprávněním aplikace ke správě přihlašovacích údajů.
Poskytnutí přihlašovacích údajů k identitě aplikace, když žádný uživatel nevysvětlí, proč je nejlepší nulová důvěra (Zero Trust) postupy pro přihlašovací údaje klienta pro služby (aplikace bez uživatele) v Azure spravované identity pro prostředky Azure.
Osvědčené postupy autorizace pomáhají implementovat nejlepší modely autorizace, oprávnění a souhlasu pro vaše aplikace.
K vytváření zabezpečených aplikací použijte osvědčené postupy pro vývoj identit a přístupu nulová důvěra (Zero Trust) v životním cyklu vývoje aplikací.
Vytváření aplikací s nulová důvěra (Zero Trust) přístupem k identitě pokračuje v článku osvědčených postupů pro vývoj identit a přístupu k nulová důvěra (Zero Trust) identit a přístupu, který vám pomůže použít nulová důvěra (Zero Trust) přístup k identitě v životním cyklu vývoje softwaru (SDLC).