Přehled oprávnění a souhlasu na platformě Microsoft Identity Platform
Pro vývoj zabezpečených aplikací, které vyžadují přístup k chráněným prostředkům, je zásadní porozumět oprávněním a souhlasu na platformě Microsoft Identity Platform. Tento článek obsahuje přehled základních konceptů a scénářů souvisejících s oprávněními a souhlasem a pomáhá vývojářům aplikací žádat o potřebná autorizace od uživatelů a správců. Díky pochopení těchto konceptů můžete zajistit, aby vaše aplikace požadovaly přístup, který potřebují, a podporovaly důvěru a zabezpečení.
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. Porozumění těmto základním konceptům pomáhá vytvářet 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ář aplikací musíte určit, jak vaše aplikace přistupuje k datům. Aplikace může používat delegovaný přístup k jednání jménem přihlášeného uživatele, nebo pouze přístup pro aplikaci, kdy jedná jen 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 rozsazích najdete v rozsazích a oprávněních.
Pro uživatele se autorizace spoléhá na oprávnění udělená uživateli pro přístup k prostředku. Uživatel může mít například oprávnění k přístupu k prostředkům adresáře pomocí řízení přístupu na základě rolí Microsoft Entra (RBAC) nebo k přístupu k prostředkům, jako je pošta a kalendář, pomocí Exchange Online RBAC. Další informace o RBAC pro aplikace naleznete 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 app-only-access.
Přístup pouze pro aplikaci používá role aplikace místo delegovaných rozsahů. Při udělení souhlasu se role aplikací můžou také označovat jako aplikací oprávnění. Klientská aplikace musí mít udělena příslušná oprávnění k aplikaci prostředku, kterou 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 nemá přístup k ničemu, co přihlášený uživatel nemohl získat.
Například vezměte aplikaci, které byla udělena delegovaná oprávnění Files.Read.All na základě pověření uživatelem. Aplikace může číst pouze 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 má přístup k datům, ke kterým je oprávnění přidruženo.
Aplikace, které bylo uděleno oprávnění aplikace rozhraní Microsoft Graph API Files.Read.All, může číst libovolný soubor u nájemce pomocí Microsoft Graph API. Obecně platí, že souhlas k oprávnění aplikace vystaveným tímto rozhraním API může udělit jenom správce nebo vlastník služebního účtu 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 autorizují aplikaci k přístupu 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 je 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 tématu prostředí pro vyjádření 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í údaje, které se kontrolují, aby se určilo, jestli už je 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 právy může schválit 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.
Souhlas správce je vyžadován u žádostí o ověření, pokud ještě nebyl udělen a pokud je požadováno některé z těchto práv s vysokými privilegii.
Žá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é schválení
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á jsou předem autorizována. Díky tomu se předem autorizovaná aplikace nepožádá uživatele, aby udělili 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é by mohly udělit přístup k citlivým informacím. Mezi příklady různých systémů autorizace v Microsoftu patří Microsoft Entra předdefinované role, Azure RBAC, Exchange RBACa souhlas specifický pro prostředky Teams.