Přehled oprávnění a souhlasu na platformě Microsoft Identity Platform
Pokud chcete získat přístup k chráněnému prostředku, jako je e-mail nebo data kalendáře, potřebuje vaše aplikace autorizaci vlastníka prostředku. Vlastník prostředku může souhlasit nebo odepřít žádost vaší aplikace. Pochopení těchto základních konceptů vám pomůže vytvořit bezpečnější a důvěryhodnější aplikace, které vyžadují pouze přístup, který potřebují, když je potřebují, od uživatelů a správců.
Scénáře přístupu
Jako vývojář aplikace musíte určit, jakým způsobem bude aplikace přistupovat k datům. Aplikace může používat delegovaný přístup, jednat jménem přihlášeného uživatele nebo přístupu jen pro aplikace, a to pouze jako vlastní identita aplikace.
Delegovaný přístup (přístup jménem uživatele)
V tomto scénáři přístupu se uživatel přihlásil k klientské aplikaci. Klientská aplikace přistupuje k prostředku jménem uživatele. Delegovaný přístup vyžaduje delegovaná oprávnění. Aby bylo možné žádost provést, musí být klient i uživatel autorizovaní samostatně. Další informace o scénáři delegovaného přístupu najdete ve scénáři delegovaného přístupu.
Pro klientskou aplikaci musí být udělena správná delegovaná oprávnění. Delegovaná oprávnění se také dají označovat jako obory. Obory jsou oprávnění pro daný prostředek, který představuje, k čemu může klientská aplikace přistupovat jménem uživatele. Další informace o oborech najdete v tématech a oprávněních.
Pro uživatele se autorizace spoléhá na oprávnění, která mu byla udělena pro přístup k prostředku. Uživatel může mít například oprávnění pro přístup k prostředkům adresáře pomocí řízení přístupu na základě role (RBAC) microsoft Entra nebo přístupu k poštovním a kalendářovým prostředkům exchangem Online RBAC. Další informace o RBAC pro aplikace najdete v tématu RBAC pro aplikace.
Přístup jen pro aplikace (Přístup bez uživatele)
V tomto scénáři přístupu aplikace funguje samostatně bez přihlášení uživatele. Přístup k aplikacím se používá ve scénářích, jako je automatizace a zálohování. Tento scénář zahrnuje aplikace, které běží jako služby na pozadí nebo démony. Je vhodné, když je nežádoucí mít přihlášeného konkrétního uživatele nebo když požadovaná data nemohou být vymezena na jednoho uživatele. Další informace o scénáři přístupu jen pro aplikace najdete v tématu Přístup jen pro aplikace.
Přístup jen pro aplikaci používá role aplikace místo delegovaných oborů. Při udělení souhlasu se role aplikací můžou také volat oprávnění aplikací. Klientská aplikace musí mít udělená příslušná oprávnění aplikace prostředku, která volá. Po udělení může klientská aplikace přistupovat k požadovaným datům. Další informace o přiřazování rolí aplikací klientským aplikacím najdete v tématu Přiřazení rolí aplikací k aplikacím.
Typy oprávnění
Delegovaná oprávnění se používají ve scénáři delegovaného přístupu. Jedná se o oprávnění, která umožňují aplikaci jednat jménem uživatele. Aplikace nebude mít nikdy přístup k ničemu, co přihlášený uživatel sám nemohl získat přístup.
Vezměte například aplikaci, která byla udělena Files.Read.All delegovaná oprávnění jménem uživatele. Aplikace bude moct číst jenom soubory, ke kterým má uživatel přístup osobně.
Oprávnění aplikace, označovaná také jako role aplikace, se používají ve scénáři přístupu jen pro aplikaci bez přítomnosti přihlášeného uživatele. Aplikace bude mít přístup k datům, ke kterým je oprávnění přidruženo.
Například aplikace, která udělila oprávnění Files.Read.All aplikace rozhraní Microsoft Graph API, bude moct číst libovolný soubor v tenantovi pomocí Microsoft Graphu. Obecně platí, že oprávnění aplikace vystavená tímto rozhraním API může udělit souhlas pouze správce nebo vlastník instančního objektu rozhraní API.
Porovnání delegovaných oprávnění a oprávnění aplikace
| Typy oprávnění | Delegovaná oprávnění | Oprávnění aplikace |
|---|---|---|
| Typy aplikací | Web / Mobilní / jednostránkové aplikace (SPA) | Web nebo proces démon |
| Kontext přístupu | Získání přístupu jménem uživatele | Získání přístupu bez uživatele |
| Kdo může vyjádřit souhlas | - Uživatelé můžou souhlasit se svými daty – Správci můžou souhlasit se všemi uživateli. |
Pouze správce může vyjádřit souhlas. |
| Metody souhlasu | - Statické: nakonfigurovaný seznam při registraci aplikace – Dynamická: Žádost o jednotlivá oprávnění při přihlášení |
– Pouze statická: nakonfigurovaný seznam při registraci aplikace |
| Další názvy | -Oblasti – Obory oprávnění OAuth2 |
– Role aplikací – Oprávnění jen pro aplikaci |
| Výsledek souhlasu (specifické pro Microsoft Graph) | OAuth2PermissionGrant | appRoleAssignment |
Souhlas
Jedním ze způsobů, jak aplikace mají udělená oprávnění, je souhlas. Souhlas je proces, kdy uživatelé nebo správci autorizuje aplikaci pro přístup k chráněnému prostředku. Když se například uživatel poprvé pokusí přihlásit k aplikaci, může aplikace požádat o oprávnění k zobrazení profilu uživatele a čtení obsahu poštovní schránky uživatele. Uživatel zobrazí seznam oprávnění, která aplikace požaduje, prostřednictvím výzvy k vyjádření souhlasu. Mezi další scénáře, ve kterých se uživatelům může zobrazit výzva k vyjádření souhlasu, patří:
- Pokud byl dříve udělen souhlas odvolán.
- Když je aplikace kódovaná tak, aby se při přihlašování výslovně zobrazila výzva k vyjádření souhlasu.
- Pokud aplikace použije dynamický souhlas k vyžádání nových oprávnění podle potřeby v době běhu.
Klíčové podrobnosti výzvy k vyjádření souhlasu jsou seznamem oprávnění, která aplikace vyžaduje, a informace o vydavateli. Další informace o výzvě k vyjádření souhlasu a prostředí souhlasu pro správce i koncové uživatele najdete v prostředí souhlasu aplikace.
Souhlas uživatele
Souhlas uživatele nastane, když se uživatel pokusí přihlásit k aplikaci. Uživatel poskytne přihlašovací přihlašovací údaje, které se kontrolují a určují, jestli už byl udělen souhlas. Pokud neexistuje žádný předchozí záznam souhlasu uživatele nebo správce s požadovanými oprávněními, zobrazí se uživateli výzva k vyjádření souhlasu a zobrazí se výzva k udělení požadovaných oprávnění aplikaci. Správce může být nutný k udělení souhlasu jménem uživatele.
Souhlas správce
V závislosti na oprávněních, která vyžadují, můžou některé aplikace vyžadovat, aby správce byl správcem, který uděluje souhlas. Například oprávnění aplikace a mnoho delegovaných oprávnění s vysokými oprávněními může udělit souhlas pouze správce.
Správci můžou udělit souhlas pro sebe nebo pro celou organizaci. Další informace o souhlasu uživatele a správce najdete v přehledu souhlasu uživatele a správce.
Žádosti o ověření se zobrazí výzva k vyjádření souhlasu správce, pokud nebyl udělen souhlas a pokud se požaduje některá z těchto oprávnění s vysokými oprávněními.
Žádosti o oprávnění, které obsahují vlastní obory aplikací, se nepovažují za vysoké oprávnění, a proto nevyžadují souhlas správce.
Předběžné ověření
Předběžné ověření umožňuje vlastníkovi aplikace prostředků udělit oprávnění, aniž by uživatelé museli zobrazit výzvu k vyjádření souhlasu pro stejnou sadu oprávnění, která byla předem autorizována. Tímto způsobem aplikace, která byla předem autorizována, nebude uživatele žádat o souhlas s oprávněními. Vlastníci prostředků můžou předem autorizovat klientské aplikace na webu Azure Portal nebo pomocí PowerShellu a rozhraní API, jako je Microsoft Graph.
Jiné systémy autorizace
Architektura souhlasu je pouze jedním ze způsobů, jak může mít aplikace nebo uživatel oprávnění pro přístup k chráněným prostředkům. Správci by měli vědět o jiných autorizačních systémech, které můžou udělit přístup k citlivým informacím. Mezi příklady různých systémů autorizace v Microsoftu patří předdefinované role Entra, Azure RBAC, Exchange RBAC a souhlas specifické pro prostředky Teams.