Engedélyek és hozzájárulás a Microsoft Identitásplatform

Az alkalmazással integrálható Microsoft Identitásplatform engedélyezési modellt követnek, amely lehetővé teszi a felhasználók és a rendszergazdák számára az adatokhoz való hozzáférés szabályozását. Az engedélyezési modell implementációja frissült a Microsoft Identitásplatform. Megváltoztatja, hogyan kell egy alkalmazásnak interakcióba lépnie a Microsoft Identitásplatform. Ez a cikk az engedélyezési modell alapvető fogalmait, beleértve a hatókörök, az engedélyek és a hozzájárulás fogalmát is.

Hatókörök és engedélyek

A Microsoft Identitásplatform OAuth 2.0 engedélyezési protokollt implementálja. Az OAuth 2.0 egy olyan módszer, amellyel egy külső alkalmazás hozzáférhet a webes erőforrásokhoz egy felhasználó nevében. A webalkalmazással integrálható Microsoft Identitásplatform rendelkezik erőforrás-azonosítóval vagy alkalmazásazonosító URI-val.

Íme néhány példa a Microsoft által üzemeltetett webes erőforrásokra:

  • Microsoft Graph:https://graph.microsoft.com
  • Microsoft 365 Mail API:https://outlook.office.com
  • Azure Key Vault: https://vault.azure.net

Ugyanez vonatkozik minden olyan külső erőforrásra, amely integrálva van a Microsoft Identitásplatform. Ezen erőforrások bármelyike meghatározhat engedélyeket, amelyek segítségével az erőforrás funkciói kisebb adattömbökre oszthatóak. A Microsoft Graph többek között a következő feladatok elvégzésére vonatkozó engedélyekkel rendelkezik:

  • Felhasználó naptárának olvasása
  • Írás egy felhasználó naptárába
  • E-mail küldése felhasználóként

Az ilyen típusú engedélydefiníciók miatt az erőforrást az adatok és az API-funkciók elérhetővé tevésének finomhangolt szabályozása biztosítja. Egy külső alkalmazás kérheti ezeket az engedélyeket a felhasználóktól és a rendszergazdáktól, akiknek jóvá kell hagyniuk a kérelmet, mielőtt az alkalmazás hozzáférhetne az adatokhoz, vagy a felhasználó nevében cselekedne.

Ha egy erőforrás funkcióit kis engedélycsoportokra darablik, külső alkalmazások építhetőek fel úgy, hogy csak a funkciójuk elvégzéséhez szükséges engedélyeket kérik le. A felhasználók és a rendszergazdák tudják, hogy milyen adatokhoz férhetnek hozzá az alkalmazás. Emellett biztosabb lehet abban, hogy az alkalmazás nem rosszindulatú szándékkal viselkedik. A fejlesztőknek mindig meg kell felelniük a legkisebb jogosultság elvének, és csak az alkalmazások működéséhez szükséges engedélyeket kell kérniük.

Az OAuth 2.0-ban ezeket az engedélykészleteket hatóköröknek nevezzük. Ezeket gyakran engedélyeknek is nevezik. A Microsoft Identitásplatform egy engedély sztringértékként van ábrázolva. Az alkalmazás úgy kéri le a szükséges engedélyeket, hogy megadja az engedélyt a scope lekérdezési paraméterben. Az identitásplatform számos jól meghatározott OpenID Csatlakozás-hatókört, valamint erőforrás-alapú engedélyeket támogat (az engedélyeket az engedély értékének az erőforrás azonosítójának vagy alkalmazásazonosító URI-jának hozzáfűzése jelzi). Az engedélysring például arra használható, hogy engedélyt kérjen a Felhasználók naptárának olvasásához a https://graph.microsoft.com/Calendars.Read Microsoft Graph.

Az alkalmazások leggyakrabban úgy kérik ezeket az engedélyeket, hogy meghatározzák a hatókörök körét a Microsoft Identitásplatform végpontra. Bizonyos magas szintű jogosultságok azonban csak rendszergazdai jóváhagyással adhatók meg. Ezek a rendszergazdai jóváhagyás végpontjával kérhetőek vagy adhatók meg. További információért olvass tovább.

A Microsoft Identity platform engedélyezési, jogkivonat- vagy hozzájárulási végpontjaira vonatkozó kérések esetén, ha az erőforrás-azonosító nincs megadva a scope paraméterben, a rendszer azt feltételezi, hogy az erőforrás Microsoft Graph. Például a scope=User.Read egyenértékű a következővel: https://graph.microsoft.com/User.Read.

Engedélytípusok

A Microsoft Identitásplatform kétféle engedélytípust támogat: delegált engedélyeket és alkalmazásengedélyeket.

  • A delegált engedélyeket olyan alkalmazások használják, amelyek bejelentkezett felhasználóval vannak jelen. Ezekhez az alkalmazásokhoz a felhasználó vagy egy rendszergazda hozzájárul az alkalmazás által kért engedélyekhez. Az alkalmazás delegálva van azzal a engedéllyel, hogy bejelentkezett felhasználóként viselkedjen, amikor hívásokat kezdeményez a célerőforráshoz.

    Egyes delegált engedélyeket nem rendszergazdák is hagyhatnak. Egyes magas jogosultsági szintű engedélyekhez azonban rendszergazdai jóváhagyásra van szükség. Ha meg szeretne tudni, hogy mely rendszergazdai szerepkörök járulnak hozzá a delegált engedélyekhez, tekintse meg a Rendszergazdai szerepkör engedélyei a Azure Active Directory (Azure AD) dokumentumban.

  • Az alkalmazásengedélyeket olyan alkalmazások használják, amelyek bejelentkezett felhasználó nélkül futnak, például olyan alkalmazások, amelyek háttérszolgáltatásként vagy démonként futnak. Az alkalmazásengedélyeket csak rendszergazda hagyhatja el.

A hatályos engedélyek azok az engedélyek, amelyekre az alkalmazásnak akkor van engedélye, amikor kéréseket ad a célerőforrásnak. Fontos megérteni a különbséget a delegált és az alkalmazásengedélyek között, amelyek az alkalmazás számára meg vannak adni, valamint hogy az alkalmazás milyen hatályos engedélyeket kap, amikor hívásokat kezdeményez a célerőforráshoz.

  • A delegált engedélyeknél az alkalmazás hatályos engedélyei az alkalmazás által megadott delegált engedélyek (hozzájárulással) és az aktuálisan bejelentkezett felhasználó jogosultságai legkevesebb jogosultsággal rendelkező metszetét metszete. Az alkalmazásnak soha nem lehet több jogosultsága, mint a bejelentkezett felhasználónak.

    A szervezeteken belül a bejelentkezett felhasználó jogosultságait szabályzat vagy egy vagy több rendszergazdai szerepkör tagja határozza meg. Ha meg szeretne tudni, hogy mely rendszergazdai szerepkörök járulnak hozzá a delegált engedélyekhez, tekintse meg a Rendszergazdai szerepkör engedélyei az Azure AD-ban.

    Tegyük fel például, hogy az alkalmazás a User.ReadWrite.All delegált engedélyt megkapta. Ez az engedély névlegesen ad engedélyt az alkalmazás számára egy cégben lévő összes felhasználó profiljának olvasásához és frissítéséhez. Ha a bejelentkezett felhasználó globális rendszergazda, az alkalmazás a szervezet minden felhasználójának profilját frissítheti. Ha azonban a bejelentkezett felhasználó nem rendszergazdai szerepkört tölt be, az alkalmazás csak a bejelentkezett felhasználó profilját tudja frissíteni. Nem tudja frissíteni a szervezet más felhasználóinak profiljait, mert az a felhasználó, aki számára jogosultsággal rendelkezik, nem rendelkezik ilyen jogosultságokkal.

  • Alkalmazásengedélyek használata során az alkalmazás hatályos engedélyei az engedély által felhozott jogosultságok teljes szintjei. Például egy Olyan alkalmazás, amely User.ReadWrite.All alkalmazásengedélysel rendelkezik, frissítheti a szervezet minden felhasználója profilját.

OpenID Csatlakozás hatókörök

Az Microsoft Identitásplatform OpenID Csatlakozás implementációja néhány jól meghatározott hatókörrel rendelkezik, amelyek szintén a Microsoft openid Graph, email , profile és offline_access . A address és phone az OpenID Csatlakozás a hatókörök nem támogatottak.

Ha az OpenID-Csatlakozás és egy tokent kér, egy jogkivonatot fog kapni a UserInfo végpont híváshoz.

Openid

Ha egy alkalmazás OpenID-Csatlakozás használatávaljelentkezik be, le kell kérnie a openid hatókört. A hatókör bejelentkezési engedélyként jelenik meg a munkahelyi fiók openid hozzájárulási oldalán. A személyes Microsoft-fiók lapon a saját profiljának megtekintése és az alkalmazásokhoz és szolgáltatásokhoz való csatlakozás a saját engedélyével Microsoft-fiók jelenik meg.

Ezzel az engedéllyel az alkalmazás egyedi azonosítót kaphat a felhasználóhoz a jogcím sub formájában. Az engedély a UserInfo végponthoz is hozzáférést biztosít az alkalmazásnak. A openid hatókör a jogkivonat végpontjának Microsoft Identitásplatform azonosító jogkivonatok lekért használhatja. Az alkalmazás használhatja ezeket a jogkivonatokat a hitelesítéshez.

e-mail

A hatókör a hatókörrel és bármely más hatókörrel email openid együtt használható. Hozzáférést biztosít az alkalmazásnak a felhasználó elsődleges e-mail-címéhez a jogcím email formájában.

A email jogcím csak akkor szerepel a jogkivonatban, ha egy e-mail-cím van társítva a felhasználói fiókhoz, ami nem mindig történik meg. Ha az alkalmazás a hatókört használja, az alkalmazásnak képesnek kell lennie kezelni egy olyan esetet, amikor nincs jogcím email a email jogkivonatban.

profil

A hatókör a hatókörrel és bármely más hatókörrel profile openid együtt használható. Hozzáférést biztosít az alkalmazásnak a felhasználóval kapcsolatos nagy mennyiségű információhoz. Az elérhető információk többek között a felhasználó utónevét, vezetéknevét, előnyben részesített felhasználónevét és objektumazonosítóját tartalmazzák.

Az adott felhasználó paraméterében elérhető jogcímek teljes listájáért tekintse meg profile id_tokens a hivatkozást. id_tokens

offline_access

A offline_access hatókör hosszabb ideig biztosít hozzáférést az alkalmazás számára az erőforrásokhoz a felhasználó nevében. A hozzájárulási lapon ez a hatókör a Hozzáférés fenntartása olyan adatokhoz, amelyekhez hozzáférést adott neki.

Amikor egy felhasználó jóváhagyja a hatókört, az alkalmazás frissítési jogkivonatokat fogadhat a Microsoft Identitásplatform offline_access jogkivonatvégpontról. A frissítési jogkivonatok hosszú életűek. Az alkalmazás új hozzáférési jogkivonatokat kap, amint a régebbiek lejárnak.

Megjegyzés

Ez az engedély jelenleg minden hozzájárulási oldalon megjelenik, még olyan folyamatoknál is, amelyek nem biztosítanak frissítési jogkivonatot (például az implicit folyamatot). Ez a beállítás olyan helyzetekkel foglalkozik, ahol az ügyfél az implicit folyamaton belül kezdődhet, majd továbbléphet arra a kódfolyamra, ahol frissítési jogkivonat várható.

A Microsoft Identitásplatform (a 2.0-s végpontra vonatkozó kérések) az alkalmazásnak explicit módon le kell kérnie a hatókört a frissítési offline_access jogkivonatok fogadására. Így amikor az OAuth 2.0hitelesítési kódfolyamában bevált egy engedélyezési kódot, csak egy hozzáférési jogkivonatot kap a /token végponttól.

A hozzáférési jogkivonat rövid ideig érvényes. Általában egy óra múlva lejár. Ezen a ponton az alkalmazásnak vissza kell irányítania a felhasználót a végpontra egy új engedélyezési /authorize kód le kéréséhez. Az átirányítás során az alkalmazás típusától függően előfordulhat, hogy a felhasználónak újra meg kell adnia a hitelesítő adatait, vagy ismét meg kell adnia az engedélyeket.

A frissítési jogkivonatok lekért és használatának további információiért tekintse meg a Microsoft Identitásplatform protokoll referenciáját.

A Microsoft Identitásplatform a hozzájárulásra támaszkodnak a szükséges erőforrásokhoz vagy API-khoz való hozzáféréshez. Különböző típusú jóváhagyások léteznek, amelyeket az alkalmazásnak esetleg ismernie kell a sikeres működés érdekében. Az engedélyek meghatározásakor azt is tudnia kell, hogyan fognak hozzáférni a felhasználók az alkalmazáshoz vagy az API-hoz.

A statikus felhasználói hozzájárulási forgatókönyvben meg kell adnia az összes szükséges engedélyt az alkalmazás konfigurációjában a Azure Portal. Ha a felhasználó (vagy adott esetben a rendszergazda) nem adott jóváhagyást az alkalmazáshoz, akkor Microsoft Identitásplatform a felhasználónak a hozzájárulását fogja kérni.

A statikus engedélyek azt is lehetővé teszik, hogy a rendszergazdák a szervezet összes felhasználója nevében járulnak hozzá.

Bár az alkalmazásban meghatározott alkalmazás statikus engedélyeinek Azure Portal és egyszerűnek kell tartania a kódot, ez néhány lehetséges problémát jelent a fejlesztők számára:

  • Az alkalmazásnak minden szükséges engedélyt le kell kérnie a felhasználó első bejelentkezéséhez. Ez az engedélyek hosszú listájához vezethet, amely elriaszthatja a végfelhasználókat az alkalmazáshoz való hozzáférés jóváhagyásáról a kezdeti bejelentkezéskor.

  • Az alkalmazásnak minden olyan erőforrást tudnia kell, amelyhez előre hozzá fog férni. Nehéz olyan alkalmazásokat létrehozni, amelyek tetszőleges számú erőforráshoz férhetnek hozzá.

A Microsoft Identitásplatform figyelmen kívül hagyhatja az alkalmazásregisztrációs adatokban meghatározott statikus engedélyeket a Azure Portal és kérheti az engedélyeket növekményesen. Az engedélyek minimális készletét előre kérheti, és idővel többet is kérhet, mivel az ügyfél további alkalmazás-funkciókat használ. Ezt úgy adhatja meg, hogy az alkalmazásnak bármikor milyen hatókörökre van szüksége, ha az új hatókörök bele vannak adva a paraméterbe a hozzáférési jogkivonat kérelmezése során – anélkül, hogy előre meg kellene határozni őket az alkalmazásregisztrációs scope információkban. Ha a felhasználó még nem járult hozzá a kérelemhez hozzáadott új hatókörökbe, a rendszer csak az új engedélyekre fogja kérni. A növekményes vagy dinamikus jóváhagyás csak a delegált engedélyekre vonatkozik, az alkalmazásengedélyekre nem.

Ha lehetővé teszi, hogy egy alkalmazás dinamikusan kérjen engedélyeket a paraméterrel, a fejlesztők teljes körűen szabályozni lehet a scope felhasználói élményt. Előre is betöltheti a hozzájárulási élményt, és egyetlen kezdeti engedélyezési kérelemben kérheti az összes engedélyt. Ha az alkalmazásnak sok engedélyre van szüksége, ezeket az engedélyeket fokozatosan gyűjtheti a felhasználótól, miközben az alkalmazás bizonyos funkcióit próbálja idővel használni.

Fontos

A dinamikus jóváhagyás kényelmes lehet, de nagy kihívást jelent a rendszergazdai jóváhagyást igénylő engedélyek számára, mert a rendszergazdai jóváhagyás használatakor ezek az engedélyek ismeretlenek a jóváhagyáskor. Ha rendszergazdai jogosultságokkal rendelkező engedélyekre van szüksége, vagy ha az alkalmazása dinamikus jóváhagyást használ, regisztrálnia kell az Azure Portal összes engedélyét (nem csak a rendszergazdai jóváhagyást igénylő engedélyek egy részkészletét). Ez lehetővé teszi a bérlői rendszergazdák számára, hogy az összes felhasználójuk nevében járulnak hozzá.

Rendszergazdai jóváhagyásra van szükség, ha az alkalmazásnak bizonyos magas jogosultsági szintű engedélyekhez kell hozzáférnie. A rendszergazdai jóváhagyás biztosítja, hogy a rendszergazdák további vezérlőkkel rendelkezzenek, mielőtt engedélyeznék, hogy az alkalmazások vagy felhasználók magas jogosultságú adatokat érjenek el a cégben.

A szervezet nevében végzett rendszergazdai jóváhagyáshoz továbbra is szükség van az alkalmazáshoz regisztrált statikus engedélyekre. Állítsa be ezeket az engedélyeket az alkalmazásokhoz az alkalmazásregisztrációs portálon, ha rendszergazdára van szüksége ahhoz, hogy a teljes szervezet nevében jóváhagyást adjon. Ez csökkenti a szervezet rendszergazdája által az alkalmazás beállításához szükséges ciklusokat.

OpenID-Csatlakozás OAuth 2.0 hitelesítési kérelemben az alkalmazás a lekérdezési paraméter használatával kérheti a szükséges scope engedélyeket. Amikor például egy felhasználó bejelentkezik egy alkalmazásba, az alkalmazás az alábbi példához hasonló kérést küld. (Az olvashatóság érdekében sortörések vannak hozzáadva.)

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=
https%3A%2F%2Fgraph.microsoft.com%2Fcalendars.read%20
https%3A%2F%2Fgraph.microsoft.com%2Fmail.send
&state=12345

A paraméter az alkalmazás által kért delegált engedélyek szóközrel scope elválasztott listája. Az egyes engedélyeket az erőforrás azonosítójának (az alkalmazásazonosító URI-jának) az engedélyértékhez való hozzáfűzése jelzi. A kérés példájában az alkalmazásnak engedéllyel kell rendelkeznie a felhasználó naptárának olvasására és e-mailek felhasználóként való elküldére.

Miután a felhasználó megadotta a hitelesítő adatait, a Microsoft Identitásplatform a felhasználói hozzájárulás egyező rekordját ellenőrzi. Ha a felhasználó korábban nem hagyta jóvá a kért engedélyeket, és a rendszergazda nem hagyta jóvá ezeket az engedélyeket a teljes szervezet nevében, a Microsoft Identitásplatform megkéri a felhasználót, hogy adja meg a kért engedélyeket.

Jelenleg a ("Hozzáférés fenntartása az adatokhoz, amelyekhez hozzáférést adott neki") engedély és a ("Bejelentkezés és a profil olvasása") engedély automatikusan szerepel az alkalmazás kezdeti offline_access user.read hozzájárulásában. Ezek az engedélyek általában szükségesek a megfelelő alkalmazásfunkciókhoz. Az engedély hozzáférést biztosít az alkalmazásnak a natív alkalmazások és webalkalmazások számára kritikus jogkivonatok offline_access frissítéséhez. Az user.read engedély hozzáférést biztosít a sub jogcímhez. Lehetővé teszi az ügyfél vagy alkalmazás számára, hogy idővel helyesen azonosítsa a felhasználót, és hozzáfér a felhasználói adatokhoz.

Példa képernyőkép a munkahelyi fiók hozzájárulásával.

Amikor a felhasználó jóváhagyja az engedélykérést, a hozzájárulás rögzítve lesz. A felhasználónak nem kell újra hozzájárulni, amikor később bejelentkezik az alkalmazásba.

Amikor egy szervezet licencet vagy előfizetést vásárol egy alkalmazáshoz, a szervezet gyakran proaktív módon szeretné beállítani az alkalmazást a szervezet összes tagja számára. A folyamat részeként a rendszergazda engedélyt adhat arra, hogy az alkalmazás a bérlő bármely felhasználója nevében jár el. Ha a rendszergazda jóváhagyást ad a teljes bérlőhöz, a szervezet felhasználói nem látják az alkalmazáshoz a hozzájárulási oldalt.

A szervezet nevében végzett rendszergazdai jóváhagyáshoz az alkalmazáshoz regisztrált statikus engedélyekre van szükség. Állítsa be ezeket az engedélyeket az alkalmazásokhoz az alkalmazásregisztrációs portálon, ha rendszergazdára van szüksége ahhoz, hogy a teljes szervezet nevében jóváhagyást adjon.

Ha a bérlő összes felhasználójára vonatkozó delegált engedélyekre vonatkozó jóváhagyást igényel, az alkalmazás a rendszergazdai hozzájárulási végpontot használhatja.

Emellett az alkalmazásoknak a rendszergazdai hozzájárulási végpontot kell használniuk az alkalmazásengedélyek igényléséhez.

Rendszergazda által korlátozott engedélyek

A Microsoft-erőforrások egyes magas szintű jogosultsági engedélyei beállíthatók rendszergazda által korlátozottra. Íme néhány példa az ilyen típusú engedélyekre:

  • Az összes felhasználó teljes profiljának olvasása a használatával User.Read.All
  • Adatok írása egy szervezet könyvtárába a használatával Directory.ReadWrite.All
  • Egy szervezet címtárában található összes csoport olvasása a következővel: Groups.Read.All

Megjegyzés

A Microsoft Identity platform engedélyezési, jogkivonat- vagy hozzájárulási végpontjainak kérései esetén, ha az erőforrás-azonosító nincs megadva a hatókörparaméterben, a rendszer azt feltételezi, hogy az erőforrás Microsoft Graph. Például a scope=User.Read egyenértékű a következővel: https://graph.microsoft.com/User.Read.

Bár a fogyasztói felhasználók hozzáférést adhatnak egy alkalmazás számára az ilyen típusú adatokhoz, a szervezeti felhasználók nem adhatnak hozzáférést ugyanazokhoz a bizalmas vállalati adatokhoz. Ha az alkalmazás hozzáférést kér ezen engedélyek egyikéhez egy szervezeti felhasználótól, a felhasználó egy hibaüzenetet kap, amely szerint nem jogosult az alkalmazás engedélyeinek igénylésére.

Ha az alkalmazásnak rendszergazda által korlátozott engedélyek hatókörére van szüksége, a szervezet rendszergazdájának el kell látnia ezeket a hatókört a szervezet felhasználói nevében. Az alkalmazás a rendszergazdai hozzájárulási végpontot használhatja, hogy ne jelenítsen meg olyan felhasználói kéréseket, amelyek nem adhatnak engedélyt a felhasználóknak. A rendszergazdai jóváhagyás végpontját a következő szakasz tartalmazza.

Ha az alkalmazás magas jogosultságú delegált engedélyeket kér, és egy rendszergazda a rendszergazdai hozzájárulási végponton keresztül adja meg ezeket az engedélyeket, a rendszer a bérlő összes felhasználója számára jóváhagyást ad.

Ha az alkalmazás alkalmazásengedélyeket kér, és egy rendszergazda adja meg ezeket az engedélyeket a rendszergazdai hozzájárulási végponton keresztül, akkor ez az engedély nem egy adott felhasználó nevében történik. Ehelyett az ügyfélalkalmazás közvetlenül kap engedélyeket. Az ilyen típusú engedélyeket csak démonszolgáltatások és más, a háttérben futó nem interaktív alkalmazások használják.

Miután a rendszergazdai hozzájárulási végponttal adta meg a rendszergazdai jóváhagyást, már készen is van. A felhasználóknak nincs szükségük további beavatkozásra. A rendszergazdai jóváhagyást követően a felhasználók egy tipikus hitelesítési folyamaton keresztül kaphatnak hozzáférési jogkivonatot. Az eredményül kapott hozzáférési jogkivonat rendelkezik a szükséges engedélyekkel.

Ha egy globális rendszergazda használja az alkalmazást, és a rendszer a jogosultsági végpontra irányítja, a Microsoft Identitásplatform észleli a felhasználó szerepkörét. Megkérdezi, hogy a globális rendszergazda a teljes bérlő nevében szeretne-e jóváhagyást adni a kért engedélyekhez. Ehelyett egy dedikált rendszergazdai hozzájárulási végponttal proaktív módon kérheti a rendszergazdát, hogy adja meg az engedélyt a teljes bérlő nevében. Ez a végpont az alkalmazásengedélyek igénylése során is szükséges. Az alkalmazásengedélyek nem kérhetőek az engedélyvégpont használatával.

Ha követi ezeket a lépéseket, az alkalmazás a bérlő összes felhasználója számára engedélyeket kérhet, beleértve a rendszergazda által korlátozott hatókörökét is. Ez a művelet magas szintű jogosultsággal rendelkezik. A műveletet csak akkor használja, ha szükséges a forgatókönyvhöz.

A lépéseket megvalósító kódmintát a rendszergazda által korlátozott hatókörök mintában láthatja a GitHub.

Engedélyek kérése az alkalmazásregisztrációs portálon

Az alkalmazásregisztrációs portálon az alkalmazások listába sorolják a szükséges engedélyeket, beleértve a delegált és az alkalmazásengedélyeket is. Ez a beállítás lehetővé teszi a hatókör és a Azure Portal rendszergazdai hozzájárulás /.default megadása beállítását.

Az engedélyeket általában statikusan kell meghatározni egy adott alkalmazáshoz. Az alkalmazás által dinamikusan vagy növekményesen lekért engedélyeket kell átfedni.

Megjegyzés

Az alkalmazásengedélyek csak a használatával /.default kérhetőek. Ha tehát az alkalmazásnak alkalmazásengedélyre van szüksége, ellenőrizze, hogy szerepel-e az alkalmazásregisztrációs portálon.

Egy alkalmazás statikusan kért engedélyeinek listájának konfigurálása:

  1. Az alkalmazáshoz a Azure Portal – Alkalmazásregisztrációk útmutatóban.
  2. Válasszon ki egy alkalmazást, vagy hozzon létre egy alkalmazást, ha még nem.
  3. Az alkalmazás Áttekintés lapján, a Kezelés alatt válassza az API-engedélyek > Engedély hozzáadása lehetőséget.
  4. Az elérhető API-k listájából válassza a Microsoft Graph lehetőséget. Ezután adja hozzá az alkalmazáshoz szükséges engedélyeket.
  5. Válassza az Engedélyek hozzáadása lehetőséget.

Amikor olyan alkalmazást hoz létre, amely a rendszergazdai hozzájárulási végpontot használja, az alkalmazásnak általában szüksége van egy lapra vagy nézetre, amelyen a rendszergazda jóváhagyhatja az alkalmazás engedélyét. Ez az oldal a következő lehet:

  • Az alkalmazás bejelentkezési folyamatának egy része.
  • Az alkalmazás beállításainak egy része.
  • Egy dedikált "csatlakozás" folyamat.

Sok esetben logikus, hogy az alkalmazás ezt a "kapcsolódási" nézetet csak azután mutassa, hogy egy felhasználó munkahelyi vagy iskolai Microsoft-fiók bejelentkezett Microsoft-fiók.

Amikor bejelentkezik a felhasználóval az alkalmazásba, azonosíthatja a szervezetet, amelyhez a rendszergazda tartozik, mielőtt megkéri, hogy hagyja jóvá a szükséges engedélyeket. Bár ez a lépés nem feltétlenül szükséges, segíthet intuitívabb felhasználói élményt létrehozni a szervezeti felhasználók számára.

A felhasználó bejelentkezéshez kövesse a Microsoft Identitásplatform oktatóanyagokat.

Engedélyek kérése egy címtár-rendszergazdától

Ha készen áll arra, hogy engedélyeket kérjen a szervezet rendszergazdájatól, átirányíthatja a felhasználót a rendszergazdai Microsoft Identitásplatform végpontjára.

// Line breaks are for legibility only.
GET https://login.microsoftonline.com/{tenant}/v2.0/adminconsent?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&state=12345
&redirect_uri=http://localhost/myapp/permissions
&scope=
https://graph.microsoft.com/calendars.read
https://graph.microsoft.com/mail.send
Paraméter Feltétel Leírás
tenant Kötelező Az a címtárbérlő, amelytől engedélyeket szeretne kérni. Guid vagy rövid név formátumban is meg lehet adni. Vagy általánosan hivatkozhat a szervezetekre, ahogy az a példában is látható. Ne használja a "common" (gyakori) lehetőséget, mert a személyes fiókok csak a bérlő kontextusában tudnak rendszergazdai jóváhagyást adni. A bérlőket kezelő személyes fiókokkal való lehető legjobb kompatibilitás érdekében használja a bérlőazonosítót, ha lehetséges.
client_id Kötelező Az alkalmazás (ügyfél) azonosítója, Azure Portal – Alkalmazásregisztrációk az alkalmazáshoz rendelt felhasználói élményt.
redirect_uri Kötelező Az átirányítási URI, ahová el szeretné küldeni a választ, hogy az alkalmazás kezelni tudja. Pontosan meg kell egyeznie az alkalmazásregisztrációs portálon regisztrált átirányítási URI-k egyikének.
state Ajánlott A kérésben szereplő érték, amely szintén a jogkivonat válaszában lesz visszaadva. Ez bármilyen tartalom sztringe lehet. Az állapot használatával kódoljon információkat a felhasználó alkalmazásbeli állapotáról a hitelesítési kérelem beeste előtt, például az oldalon vagy a megtekintésben, ahol voltak.
scope Kötelező Meghatározza az alkalmazás által kért engedélyeket. A hatókörök statikusak (a használatával) vagy /.default dinamikusak is lehetnek. Ez a készlet tartalmazhatja az OpenID Csatlakozás ( openid , profile , email ). Ha alkalmazásengedélyre van szüksége, a használatával kell lekérte a statikusan konfigurált engedélyek /.default listáját.

Az Azure AD-nek ezen a ponton be kell jelentkeznie egy bérlői rendszergazdára a kérés befejezéséhez. A rendszer megkéri a rendszergazdát, hogy hagyja jóvá a paraméterben kért összes scope engedélyt. Ha statikus ( ) értéket használt, az az 1.0-s verziójának rendszergazdai hozzájárulási végpontjaként fog működni, és jóváhagyást kér az alkalmazáshoz szükséges engedélyekben található összes /.default hatókörre.

Sikeres válasz

Ha a rendszergazda jóváhagyja az alkalmazás engedélyét, a sikeres válasz a következő lesz:

GET http://localhost/myapp/permissions?tenant=a8990e1f-ff32-408a-9f8e-78d3b9139b95&state=state=12345&admin_consent=True
Paraméter Leírás
tenant Az a címtárbérlő, amely GUID formátumban megadta az alkalmazásnak a kért engedélyeket.
state A kérésben szereplő érték, amely szintén a jogkivonat válaszában lesz visszaadva. Ez bármilyen tartalom sztringe lehet. Az állapot a felhasználó alkalmazásbeli állapotára vonatkozó információk kódolására használatos a hitelesítési kérelem beeste előtt, például az oldalon vagy a megtekintésben.
admin_consent A beállítás a True lesz.

Hibaválasz

Ha a rendszergazda nem hagyja jóvá az alkalmazás engedélyét, a sikertelen válasz a következő:

GET http://localhost/myapp/permissions?error=permission_denied&error_description=The+admin+canceled+the+request
Paraméter Leírás
error Hibakód-sztring, amely a előforduló hibatípusok besorolására használható. Arra is használható, hogy reagáljon a hibákra.
error_description Egy adott hibaüzenet, amely segíthet a fejlesztőnek a hiba kiváltó okának azonosításában.

Miután sikeresen kapott választ a rendszergazdai hozzájárulási végponttól, az alkalmazás megkapta a kért engedélyeket. Ezután kérhet egy jogkivonatot a kívánt erőforráshoz.

Engedélyek használata

Miután a felhasználó hozzájárul az alkalmazás engedélyeinek megszerzéséhez, az alkalmazás hozzáférési jogkivonatokat szerezhet be, amelyek az alkalmazásnak egy adott kapacitásban az erőforrások elérésére vonatkozó engedélyét képviselik. A hozzáférési jogkivonatok csak egyetlen erőforráshoz használhatók. A hozzáférési jogkivonatban kódolt minden olyan engedély, amely az alkalmazás számára az adott erőforráshoz hozzá lett adták. Hozzáférési jogkivonat lekéréséhez az alkalmazás az alábbihoz hasonló kérést Microsoft Identitásplatform a jogkivonat végpontjára:

POST common/oauth2/v2.0/token HTTP/1.1
Host: https://login.microsoftonline.com
Content-Type: application/json

{
    "grant_type": "authorization_code",
    "client_id": "6731de76-14a6-49ae-97bc-6eba6914391e",
    "scope": "https://outlook.office.com/mail.read https://outlook.office.com/mail.send",
    "code": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...",
    "redirect_uri": "https://localhost/myapp",
    "client_secret": "zc53fwe80980293klaj9823"  // NOTE: Only required for web apps
}

Az eredményül kapott hozzáférési jogkivonatot használhatja az erőforrásnak adott HTTP-kérésben. Megbízhatóan jelzi az erőforrásnak, hogy az alkalmazás megfelelő engedéllyel rendelkezik egy adott feladat elvégzéséhez.

Az OAuth 2.0 protokollról és a hozzáférési jogkivonatok le Microsoft Identitásplatform a végponti protokoll referenciáját.

A /.default hatókör

A hatókör használatával alkalmazásait az 1.0-s végpontról a virtuális gép végpontjára /.default Microsoft Identitásplatform át. A hatókör minden olyan alkalmazáshoz be van építve, amely az alkalmazásregisztrációban konfigurált engedélyek statikus /.default listájára hivatkozik.

A scope értéke https://graph.microsoft.com/.default funkcionálisan megegyezik az resource=https://graph.microsoft.com 1.0-s végpont értékével. A hatókör kérésben való megadásával az alkalmazás olyan hozzáférési jogkivonatot kér, amely az alkalmazáshoz az alkalmazásregisztrációs portálon kiválasztott összes https://graph.microsoft.com/.default Microsoft Graph-engedély hatókörét tartalmazza. A hatókör az erőforrás URI-ját és a használatával áll /.default össze. Tehát ha az erőforrás URI-ja https://contosoApp.com , akkor a kért hatókör a https://contosoApp.com/.default következő: . Olyan esetekben, amikor egy második perjelet kell használnia a jogkivonat helyes lekérése érdekében, tekintse meg a záró perjelekkel kapcsolatos szakaszt.

A /.default hatókör bármely OAuth 2.0-folyamatban használható. Erre azonban szükség van a Meghatalmazásos folyamat és az ügyfél-hitelesítő adatok folyamatában. Akkor is szüksége lesz rá, ha a v2 rendszergazdai hozzájárulási végpontot használja az alkalmazásengedélyek igénylésére.

Az ügyfelek nem kombinálják a statikus ( ) hozzájárulásokat és /.default a dinamikus hozzájárulásokat egyetlen kérésben. Ezért hibát jelez, mert a scope=https://graph.microsoft.com/.default+mail.read hatókörtípusokat kombinálja.

A /.default hatókör aktiválja az 1.0-s végpont viselkedését prompt=consent is. Az alkalmazás által regisztrált összes engedélyhez jóváhagyást kér, az erőforrástól függetlenül. Ha a kérelem része, a hatókör egy jogkivonatot ad vissza, amely tartalmazza a kért erőforrás /.default hatókörét.

A /.default hatókör működése megegyezik a resource -központú 1.0-s végpont viselkedésével. Az 1.0-s végpont hozzájárulási viselkedését is tartalmazza. Ez azt jelenti, hogy csak akkor aktivál egy hozzájárulási kérést, ha a felhasználó nem adott engedélyt az ügyfél és az /.default erőforrás között.

Ha létezik ilyen hozzájárulás, a visszaadott jogkivonat tartalmazza az adott erőforráshoz a felhasználó által megadott összes hatókört. Ha azonban nem kapott engedélyt, vagy ha a paraméter meg lett adva, az ügyfélalkalmazás által regisztrált összes hatókörre jóváhagyást kér prompt=consent a rendszer.

1. példa: A felhasználó vagy a bérlői rendszergazda engedélyeket adott

Ebben a példában a felhasználó vagy egy bérlői rendszergazda megadta a és a Microsoft Graph mail.read user.read az ügyfélnek.

Ha az ügyfél a kérést kéri, a microsoftos ügyfélalkalmazáshoz regisztrált engedélyek tartalmától függetlenül nem jelenik meg scope=https://graph.microsoft.com/.default a Graph. A visszaadott jogkivonat a és a hatókört mail.read user.read tartalmazza.

2. példa: A felhasználó nem adott engedélyeket az ügyfél és az erőforrás között

Ebben a példában a felhasználó nem adott jóváhagyást az ügyfél és a Microsoft Graph. Az ügyfél regisztrált a és a user.read contacts.read engedélyre. Emellett regisztrálva van a Azure Key Vault https://vault.azure.net/user_impersonation hatókörben.

Amikor az ügyfél jogkivonatot kér a számára, a felhasználó egy hozzájárulási oldalt lát a hatókör, a hatókör és a Key Vault scope=https://graph.microsoft.com/.default user.read contacts.read user_impersonation számára. A visszaadott jogkivonat csak a és user.read contacts.read hatókört tartalmazza. Csak a Microsoft által használt Graph.

3. példa: A felhasználó hozzájárult, és az ügyfél több hatókört kér

Ebben a példában a felhasználó már hozzájárult az mail.read ügyfélhez. Az ügyfél regisztrált a contacts.read hatókörre.

Amikor az ügyfél jogkivonatot kér a használatával, és a használatával kér jóváhagyást, a felhasználó az alkalmazás által regisztrált összes (és csak) engedélyhez egy hozzájárulási scope=https://graph.microsoft.com/.default prompt=consent oldalt lát. A contacts.read hatókör a hozzájárulási oldalon található, mail.read de nem az. A visszaadott jogkivonat a Microsoft Graph. A és a elemeket mail.read contacts.read tartalmazza.

A /.default hatókör használata az ügyféllel

Bizonyos esetekben az ügyfél saját hatókört /.default kérhet. Az alábbi példa ezt a forgatókönyvet mutatja be.

// Line breaks are for legibility only.

GET https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
response_type=token            //Code or a hybrid flow is also possible here
&client_id=9ada6f8a-6d83-41bc-b169-a306c21527a5
&scope=9ada6f8a-6d83-41bc-b169-a306c21527a5/.default
&redirect_uri=https%3A%2F%2Flocalhost
&state=1234

Ez a példakód létrehoz egy jóváhagyási oldalt az összes regisztrált engedélyhez, ha a hozzájárulás fenti leírásai vonatkoznak a /.default forgatókönyvre. Ezután a kód egy id_token , és nem egy hozzáférési jogkivonatot ad vissza.

Ez a viselkedés az Azure AD Authentication Libraryről (ADAL) a Microsoft Authentication Libraryre (MSAL) való áthelyezésre használt régebbi ügyfeleket is befogadja. Ezt a beállítást nem szabad olyan új ügyfelek által használni, amelyek a Microsoft Identitásplatform.

Ügyfél-hitelesítő adatok megadása folyamat és /.default

Egy másik felhasználási lehetőség az alkalmazásengedélyek (vagy szerepkörök) kérése egy nem interaktív alkalmazásban, például egy démonalkalmazásban, amely az ügyfél hitelesítő adatait használó folyamat segítségével hív meg egy /.default webes API-t.

A webes API-k alkalmazásengedélyeinek (szerepköreinek) létrehozásához lásd: Alkalmazásszerepkszerepkörök hozzáadása az alkalmazásban.

Az ügyfélalkalmazásban az ügyfél-hitelesítő adatokra vonatkozó kérelmeknek tartalmazniuk kell a következőt: scope={resource}/.default . Itt {resource} az a webes API, amit az alkalmazás meg kíván hívni. Az ügyfél-hitelesítő adatok kérésének kiállítása egyéni alkalmazásengedélyekkel (szerepkörökkel) nem támogatott. A visszaadott hozzáférési jogkivonat tartalmazza az adott webes API-hoz megadott összes alkalmazásengedélyt (szerepkört).

Ha hozzáférést ad az Ön által megadott alkalmazásengedélyek számára, beleértve a rendszergazdai hozzájárulás megadását az alkalmazáshoz, lásd: Ügyfélalkalmazás konfigurálása webes API-k elérésére.

Záró perjel és /.default

Egyes erőforrás-URI-k záró perjellel( ) stb. vannak, nem https://contoso.com/ pedig https://contoso.com a következővel: . A záró perjel problémákat okozhat a jogkivonat érvényesítésében. A problémák elsősorban akkor fordulnak elő, ha jogkivonatot Azure Resource Manager ( https://management.azure.com/ ). Ebben az esetben az erőforrás URI-ján záró perjel azt jelenti, hogy a perjelnek jelen kell lennie a jogkivonat lekérésekor. Így amikor jogkivonatot kér a számára, és a használatával kéri https://management.azure.com/ /.default (figyelje meg a kettős https://management.azure.com//.default perjelet!). Ha általában ellenőrzi, hogy a jogkivonat ki van-e bocsátva, és az API elutasítja a jogkivonatot, amely elfogadja azt, érdemes lehet hozzáadni egy újabb perjelet, és újra próbálkozni.

Hibaelhárítási lépésekért lásd: Váratlan hiba egy alkalmazás hozzájárulásának végrehajtásakor.

Következő lépések