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 nulovou důvěryhodnost při získávání přístupových oprávnění 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í přezkum

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á k ověřování protokol OpenID Connect . 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í požadavku oprávněni samostatně. Přímý přístup může vyžadovat oprávnění aplikace (označovaná také jako role aplikací). Když aplikace přijmou role aplikací, můžeme je nazývat oprávněními aplikace.

• 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. Jenom správci a vlastníci aplikačních objektů mohou dát souhlas k oprávněním aplikace.

• Souhlas je způsob, jakým aplikace přijímají oprávnění. Uživatelé nebo správci autorizují aplikaci k přístupu 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í nějaký 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ěryhodnosti

Přístup autorizace zahrnuje ověřování jako součást při připojování uživatele k aplikaci a při přístupu k prostředku, který používáte. Když vaše aplikace působí jménem uživatele, nedůvěřujeme volající aplikaci, aby nám řekla, kdo je uživatel, nebo aby aplikace rozhodla o totožnosti uživatele. 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 zahrnují přesměrovací URI, přístupové tokeny (používané pro implicitní toky), certifikáty a tajemství, 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í při zvýšení zabezpečení nulové důvěryhodnosti aplikací 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 kontrolu při zvyšování zabezpečení nulové důvěryhodnosti aplikací 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 s využitím principů nulové důvěryhodnosti.
• 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ů.
• Poskytnutí přihlašovacích údajů identity aplikace, když není přítomen uživatel vysvětluje, proč spravované identity Azure jsou nejlepším postupem pro ověřování klienta pro služby na platformě Azure (aplikace bez uživatele).
• 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 v životním cyklu vývoje aplikací osvědčené postupy pro vývoj správy identit a přístupu s nulovou důvěryhodností.
• Vytváření aplikací s přístupem Zero Trust k identitě pokračuje z článku o osvědčených postupech pro vývoj managementu identit a přístupu Zero Trust a pomáhá vám používat přístup Zero Trust k identitě v životním cyklu vývoje softwaru (SDLC).