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

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; když vlastník prostředku odepře přístup, aplikace neobdrží přístupový token.

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.

• Delegovaný přístup (jménem přihlášeného uživatele) nebo přímý přístup (funguje jenom jako vlastní identita aplikace) umožňuje vaší aplikaci přístup k datům. 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 aplikace); 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ů .

• Souhlas je způsob, jakým aplikace přijímají oprávnění. 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.

• Předběžné ověřování je způsob, jakým vlastníci aplikací prostředků udělují přístup klientským aplikacím. Můžou to udělat 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 předem autorizovaných oprávnění.

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 má 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ěřuje a přímo poskytuje 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 přijímat v tokenech Microsoft Entra. Vysvětluje, jak přizpůsobit tokeny, 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.
• Konfigurace deklarací identity skupin a rolí aplikací v tokenech ukazuje, jak nakonfigurovat aplikace s definicemi rolí aplikace a přiřadit skupiny zabezpečení k rolím aplikací. Tyto metody pomáhají zlepšit flexibilitu a řízení a současně zvýšit 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).
• Strategie vytváření oprávnění aplikací vám pomůže rozhodnout se o přístupu k oprávněním aplikace ke správě přihlašovacích údajů.
• Zadání přihlašovacích údajů identity aplikace, když žádný uživatel nevysvětlí, proč spravované identity pro prostředky Azure představují nejlepší postup přihlašovacích údajů klienta pro služby (aplikace bez uživatelů) v 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).