Hitelesítési folyamat támogatása az MSAL-ben

A Microsoft Authentication Library (MSAL) számos engedélyezési támogatást és társított jogkivonat-folyamatot támogat, amelyeket különböző alkalmazástípusok és forgatókönyvek használhatnak.

Hitelesítési folyamat	Lehetővé teszi	Támogatott alkalmazástípusok
Engedélyezési kód	A felhasználó bejelentkezik, és a felhasználó nevében hozzáférhet a webes API-khoz.	Asztali Mobil Egyoldalas alkalmazás (SPA) (PKCE-t igényel) Web
Ügyfél-hitelesítő adatok	A webes API-k elérése az alkalmazás identitásának használatával. Általában a kiszolgáló–kiszolgáló közötti kommunikációhoz és a felhasználói beavatkozást nem igénylő automatizált szkriptekhez használják.	Daemon
Eszközkód	A felhasználó bejelentkezik, és hozzáférést biztosít a felhasználó nevében a webes API-khoz olyan bemeneti korlátozásokkal rendelkező eszközökön, mint az intelligens tévék és az IoT-eszközök. Parancssori felületi (CLI-) alkalmazások is használják.	Asztali, mobil
Implicit támogatás	A felhasználó bejelentkezik, és a felhasználó nevében hozzáférhet a webes API-khoz. Az implicit engedélyezési folyamat már nem ajánlott – használja inkább az engedélyezési kódot a PKCE-vel.	* Egyoldalas alkalmazás (SPA) * Web
Az (OBO) nevében	Hozzáférés a "felsőbb rétegbeli" webes API-ból egy "alsóbb rétegbeli" webes API-hoz a felhasználó nevében. A felhasználó identitása és delegált engedélyei a felsőbb rétegbeli API-ból kerülnek át az alsóbb rétegbeli API-ba.	Webes API
Felhasználónév/jelszó (ROPC)	Lehetővé teszi, hogy az alkalmazás közvetlenül a jelszavával jelentkezzen be a felhasználóba. A ROPC-folyamat nem ajánlott.	Asztali, mobil
Integrált Windows-hitelesítés (IWA)	Lehetővé teszi a tartományon vagy a Microsoft Entra-hoz csatlakoztatott számítógépeken futó alkalmazások számára, hogy csendben szerezzenek be egy jogkivonatot (felhasználói felületi beavatkozás nélkül).	Asztali, mobil

Tokenek

Az alkalmazás egy vagy több hitelesítési folyamatot használhat. Minden folyamat bizonyos jogkivonattípusokat használ a hitelesítéshez, az engedélyezéshez és a jogkivonat frissítéséhez, mások pedig engedélyezési kódot is használnak.

Hitelesítési folyamat vagy művelet	Szükséges	Azonosító jogkivonata	Hozzáférési jogkivonat	Jogkivonat frissítése	Engedélyezési kód
Engedélyezési kódfolyamat
Ügyfél-hitelesítő adatok			(csak alkalmazás)
Eszközkód-folyamat
Implicit folyamat
Meghatalmazásos folyamat	hozzáférési jogkivonat
Felhasználónév/jelszó (ROPC)	felhasználónév, jelszó
Hibrid OIDC-folyamat
Jogkivonat beváltásának frissítése	frissítési jogkivonat

Interaktív és nem interaktív hitelesítés

Ezen folyamatok közül több támogatja az interaktív és a nem interaktív jogkivonatok beszerzését is.

• Interaktív – Előfordulhat, hogy az engedélyezési kiszolgáló kéri a felhasználótól a bemenetet. Például bejelentkezéshez, többtényezős hitelesítéshez (MFA) vagy több erőforrás-hozzáférési engedélyhez való hozzájárulás megadásához.
• Nem interaktív (csendes) – Előfordulhat, hogy a rendszer nem kéri a felhasználótól a bemenetet. A "csendes" jogkivonat-beszerzésnek is nevezett alkalmazás egy olyan metódussal próbál jogkivonatot lekérni, amelyben az engedélyezési kiszolgáló esetleg nem kéri a felhasználótól a bemenetet.

Az MSAL-alapú alkalmazásnak először meg kell próbálnia csendesen beszerezni egy jogkivonatot, és csak akkor térjen vissza az interaktív metódusra, ha a nem interaktív kísérlet meghiúsul. További információ erről a mintáról: Jogkivonatok beszerzése és gyorsítótárazása a Microsoft Authentication Library (MSAL) használatával.

Engedélyezési kód

Az OAuth 2.0 engedélyezési kód megadását webalkalmazások, egyoldalas alkalmazások (SPA) és natív (mobil- és asztali) alkalmazások használhatják a védett erőforrásokhoz, például webes API-khoz való hozzáféréshez.

Amikor a felhasználók bejelentkeznek a webalkalmazásba, az alkalmazás kap egy engedélyezési kódot, amelyet beválthat egy hozzáférési jogkivonatra a webes API-k meghívásához.

Az alábbi ábrán az alkalmazás:

1. Hozzáférési jogkivonatra beváltott engedélyezési kódot kér
2. A hozzáférési jogkivonat használatával meghív egy webes API-t, a Microsoft Graphot

Engedélyezési kód korlátozásai

• Az egyoldalas alkalmazásokhoz a kódcsere (PKCE) ellenőrzőkulcsa szükséges az engedélyezési kód engedélyezési folyamatának használatakor. A PKCE-t az MSAL támogatja.

• Az OAuth 2.0 specifikáció megköveteli, hogy egy engedélyezési kóddal csak egyszer váltson be hozzáférési jogkivonatot.

  Ha többször is megpróbál hozzáférési jogkivonatot beszerezni ugyanazzal az engedélyezési kóddal, a Microsoft Identitásplatform az alábbihoz hasonló hibát ad vissza. Egyes kódtárak és keretrendszerek automatikusan kérik az engedélyezési kódot, és ha ilyen esetekben manuálisan kér egy kódot, az is ezt a hibát eredményezi.

  AADSTS70002: Error validating credentials. AADSTS54005: OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token.
  

Ügyfél-hitelesítő adatok

Az OAuth 2.0 ügyfél hitelesítő adatainak folyamata lehetővé teszi, hogy egy alkalmazás identitásával hozzáférjen a webes erőforrásokhoz. Ez az engedélytípus általában olyan kiszolgálóközi interakciók esetén használatos, amelyeknek a felhasználóval való azonnali interakció nélkül, a háttérben kell futniuk. Ezeket az alkalmazástípusokat gyakran démonoknak vagy szolgáltatásfiókoknak nevezik.

Az ügyfél hitelesítő adatai lehetővé teszik, hogy egy webszolgáltatás (bizalmas ügyfél) saját hitelesítő adatait használja ahelyett, hogy megszemélyesítenének egy felhasználót, hogy hitelesítést végezzen egy másik webszolgáltatás meghívásakor. Ebben a forgatókönyvben az ügyfél általában egy középső szintű webszolgáltatás, egy démonszolgáltatás vagy egy webhely. A magasabb szintű megbízhatóság érdekében a Microsoft Identitásplatform lehetővé teszi, hogy a hívó szolgáltatás hitelesítő adatként tanúsítványt használjon (a megosztott titkos kód helyett).

Alkalmazás titkos kódjai

Az alábbi ábrán az alkalmazás:

1. Jogkivonat beszerzése alkalmazás titkos kód vagy jelszó hitelesítő adataival
2. A jogkivonatot használja az erőforrás kéréseinek igényléséhez

Diplomák

Az alábbi ábrán az alkalmazás:

1. Jogkivonat beszerzése tanúsítvány hitelesítő adataival
2. A jogkivonatot használja az erőforrás kéréseinek igényléséhez

Az ügyfél hitelesítő adatainak a következőknek kell lenniük:

• Regisztrálva a Microsoft Entra-azonosítóval
• Beadva a kódban lévő bizalmas ügyfélalkalmazás-objektum létrehozásakor

Az ügyfél hitelesítő adatainak korlátozásai

A bizalmas ügyfélfolyamat nem támogatott mobilplatformokon, például Androidon, iOS-en vagy UWP-n. A mobilalkalmazások olyan nyilvános ügyfélalkalmazások, amelyek nem garantálják hitelesítő adataik titkosságát.

Eszközkód

Az OAuth 2.0 eszközkódfolyamat lehetővé teszi, hogy a felhasználók bejelentkezhessenek a bemenetre korlátozott eszközökre, például intelligens tévékre, IoT-eszközökre és nyomtatókra. A Microsoft Entra-azonosítóval való interaktív hitelesítéshez webböngésző szükséges. Ha az eszköz vagy az operációs rendszer nem biztosít webböngészőt, az eszköz kódfolyamata lehetővé teszi, hogy a felhasználó egy másik eszközt, például egy számítógépet vagy mobiltelefont használva interaktívan jelentkezzen be.

Az eszközkód-folyamat használatával az alkalmazás egy kétlépéses folyamattal szerzi be a jogkivonatokat, amelyeket ezekhez az eszközökhöz és operációs rendszerekhez terveztek. Ilyen alkalmazások például az IoT-eszközökön és parancssori felületi eszközökön futó alkalmazások.

Az alábbi ábrán:

1. Amikor felhasználói hitelesítésre van szükség, az alkalmazás megad egy kódot, és megkéri a felhasználót, hogy használjon egy másik eszközt, például egy internetkapcsolattal rendelkező okostelefont egy URL-címre (például https://microsoft.com/devicelogin). A rendszer ezután felkéri a felhasználót, hogy adja meg a kódot, és ha szükséges, folytassa a normál hitelesítési élményt, beleértve a hozzájárulási kéréseket és a többtényezős hitelesítést.
2. Sikeres hitelesítés esetén a parancssori alkalmazás egy háttércsatornán keresztül kapja meg a szükséges jogkivonatokat, és azokkal hajtja végre a szükséges webes API-hívásokat.

Eszközkód korlátozásai

• Az eszköz kódfolyamata csak nyilvános ügyfélalkalmazásokhoz érhető el.
• Amikor inicializál egy nyilvános ügyfélalkalmazást az MSAL-ben, használja az alábbi szolgáltatói formátumok egyikét:
  • Bérlő: https://login.microsoftonline.com/{tenant}/, hol {tenant} található a bérlő azonosítója vagy a bérlőhöz társított tartománynév.
  • Munkahelyi és iskolai fiókok: https://login.microsoftonline.com/organizations/.

Implicit engedélyezés

Az implicit engedélyezési folyamatot felváltotta az engedélyezési kódfolyamat, és a PKCE lett az ügyféloldali egyoldalas alkalmazások (SLA-k) előnyben részesített és biztonságosabb jogkivonat-engedélyezési folyamata. Már nem ajánlott az implicit engedélyezési folyamatot használni. Ha SPA-t hoz létre, használja inkább az engedélyezési kódfolyamatot a PKCE-vel.

A JavaScriptben írt egyoldalas webalkalmazások (például az Angular, Vue.js vagy React.js) letöltődnek a kiszolgálóról, és a kódjuk közvetlenül a böngészőben fut. Mivel az ügyféloldali kód a böngészőben fut, és nem webkiszolgálón, a hagyományos kiszolgálóoldali webalkalmazásoknál eltérő biztonsági jellemzőkkel rendelkeznek. Az engedélyezési kódfolyamathoz tartozó Proof Key for Code Exchange (PKCE) rendelkezésre állása előtt az implicit engedélyezési folyamatot az SLA-k használták a jobb válaszképesség és hatékonyság érdekében a hozzáférési jogkivonatok lekérésében.

Az OAuth 2.0 implicit engedélyezési folyamata lehetővé teszi, hogy az alkalmazás a háttérkiszolgáló hitelesítő adatainak cseréje nélkül kérje le a hozzáférési jogkivonatokat a Microsoft Identitásplatform. Az implicit engedélyezési folyamat lehetővé teszi, hogy az alkalmazás bejelentkezjen a felhasználóba, tartson fenn egy munkamenetet, és jogkivonatokat szerezzen be más webes API-khoz a felhasználói ügynök által letöltött és futtatott JavaScript-kódból (általában webböngészőből).

Implicit engedélyezés korlátozásai

Az implicit engedélyezési folyamat nem tartalmaz olyan alkalmazásforgatókönyveket, amelyek platformfüggetlen JavaScript-keretrendszereket használnak, mint például az Electron vagy a React Native. Az ilyen platformfüggetlen keretrendszerek további képességeket igényelnek azokkal a natív asztali és mobilplatformokkal való interakcióhoz, amelyeken futnak.

Az implicit folyamat móddal kibocsátott jogkivonatok hossza korlátozott, mert URL-cím alapján kerülnek vissza a böngészőbe (hol response_mode található vagyfragmentquery). Egyes böngészők korlátozzák az URL-cím hosszát a böngészősávon, és túl hosszúak. Így ezek az implicit folyamatjogkivonatok nem tartalmaznak groups vagy wids jogcímeket.

Az (OBO) nevében

Az OAuth 2.0 on-behalf-of authentication folyamat akkor használatos, ha egy alkalmazás egy olyan szolgáltatást vagy webes API-t hív meg, amelyet másik szolgáltatásnak vagy webes API-nak kell meghívnia. A cél a delegált felhasználói identitás és engedélyek propagálása a kérelemláncon keresztül. Ahhoz, hogy a középső szintű szolgáltatás hitelesített kéréseket küldjön az alsóbb rétegbeli szolgáltatásnak, egy hozzáférési jogkivonatot kell biztosítania a Microsoft Identitásplatform a felhasználó nevében.

Az alábbi ábrán:

1. Az alkalmazás egy hozzáférési jogkivonatot szerez be a webes API-hoz.
2. Egy ügyfél (webes, asztali, mobil vagy egyoldalas alkalmazás) meghív egy védett webes API-t, és a hozzáférési jogkivonatot tulajdonosi jogkivonatként adja hozzá a HTTP-kérés hitelesítési fejlécéhez. A webes API hitelesíti a felhasználót.
3. Amikor az ügyfél meghívja a webes API-t, a webes API egy másik jogkivonatot kér a felhasználó nevében.
4. A védett webes API ezt a jogkivonatot használja egy alsóbb rétegbeli webes API meghívására a felhasználó nevében. A webes API később jogkivonatokat is kérhet más alsóbb rétegbeli API-khoz (de ugyanannak a felhasználónak a nevében).

Felhasználónév/jelszó (ROPC)

Figyelmeztetés

Az erőforrás-tulajdonos jelszavas hitelesítő adatainak (ROPC) folyamata NEM ajánlott. A ROPC magas fokú megbízhatóságot és hitelesítő adatokat igényel. Csak akkor használja a ROPC-t, ha egy biztonságosabb folyamat nem használható. További információ: Mi a megoldás a jelszavak növekvő problémájára?

Az OAuth 2.0 erőforrás-tulajdonosi jelszó hitelesítő adatai (ROPC) lehetővé teszik, hogy az alkalmazás közvetlenül a jelszavával jelentkezzen be a felhasználóba. Az asztali alkalmazásban a felhasználónév/jelszó folyamatával csendben szerezhet be egy jogkivonatot. Az alkalmazás használatakor nincs szükség felhasználói felületre.

Egyes alkalmazásforgatókönyvek, például a DevOps hasznosnak találhatják a ROPC-t, de minden olyan alkalmazásban kerülnie kell, amelyben interaktív felhasználói felületet biztosít a felhasználói bejelentkezéshez.

Az alábbi ábrán az alkalmazás:

1. Jogkivonat beszerzéséhez küldje el a felhasználónevet és a jelszót az identitásszolgáltatónak
2. Webes API meghívása a jogkivonat használatával

Ha csendesen szeretne jogkivonatot beszerezni a Windows tartományhoz csatlakoztatott gépeken, javasoljuk, hogy roPC helyett integrált Windows-hitelesítést (IWA) használjon. Más forgatókönyvek esetén használja az eszköz kódfolyamatát.

A ROPC korlátozásai

A ROPC-folyamatot használó alkalmazásokra a következő korlátozások vonatkoznak:

• Az egyszeri bejelentkezés nem támogatott.
• A többtényezős hitelesítés (MFA) nem támogatott.
  • A folyamat használata előtt forduljon a bérlő rendszergazdájához – az MFA egy gyakran használt funkció.
• A feltételes hozzáférés nem támogatott.
• A ROPC csak munkahelyi és iskolai fiókokhoz használható.
• A ROPC nem támogatja a személyes Microsoft-fiókokat (MSA).
• A ROPC támogatott a .NET asztali és ASP.NET Core-alkalmazásokban.
• A ROPC nem támogatott Univerzális Windows-platform (UWP) alkalmazásokban.
• A ROPC az Azure AD B2C-ben csak helyi fiókok esetében támogatott.
  • További információ a ROPC-ról a MSAL.NET és az Azure AD B2C-ben: ROPC használata az Azure AD B2C-vel.

Integrált Windows-hitelesítés (IWA)

Az MSAL támogatja az integrált Windows-hitelesítést (IWA) a tartományhoz csatlakoztatott vagy Microsoft Entra csatlakoztatott Windows-számítógépeken futó asztali és mobilalkalmazásokhoz. Az IWA használatával ezek az alkalmazások csendben szereznek be egy jogkivonatot anélkül, hogy felhasználói beavatkozást igényelnek a felhasználók.

Az alábbi ábrán az alkalmazás:

1. Jogkivonat beszerzése integrált Windows-hitelesítéssel
2. A jogkivonatot használja az erőforrás kéréseinek igényléséhez

Az IWA korlátozásai

Kompatibilitás

Az integrált Windows-hitelesítés (IWA) engedélyezve van a .NET desktop, a .NET és a Windows Univerzális platform alkalmazásokhoz.

Az IWA csak az AD FS által összevont felhasználókat támogatja – az Active Directoryban létrehozott és a Microsoft Entra ID által támogatott felhasználókat. Ezt a hitelesítési folyamatot nem használhatják azok a felhasználók, amelyeket közvetlenül a Microsoft Entra ID-ban hoztak létre Active Directory-háttérrendszer (felügyelt felhasználók) nélkül.

Többtényezős hitelesítés (MFA)

Az IWA nem interaktív (csendes) hitelesítése meghiúsulhat, ha az MFA engedélyezve van a Microsoft Entra-bérlőben, és a Microsoft Entra ID egy MFA-kihívást állít ki. Ha az IWA meghibásodik, a korábban ismertetett interaktív hitelesítési módszerre kell visszaállnia.

A Microsoft Entra ID AI használatával határozza meg, hogy mikor van szükség kéttényezős hitelesítésre. Kétfaktoros hitelesítésre általában akkor van szükség, ha egy felhasználó egy másik országból vagy régióból jelentkezik be, amikor VPN használata nélkül csatlakozik egy vállalati hálózathoz, és néha vpn-en keresztül csatlakozik. Mivel az MFA konfigurációja és a kihívások gyakorisága fejlesztőként kívül esik az Ön vezérlésén, az alkalmazásnak kecsesen kell kezelnie az IWA csendes jogkivonat-beszerzésének meghiúsulását.

Szolgáltatói URI-korlátozások

A nyilvános ügyfélalkalmazás létrehozásakor átadott szolgáltatónak az alábbiak egyikének kell lennie:

• https://login.microsoftonline.com/{tenant}/ – Ez a szolgáltató egy bérlős alkalmazást jelöl, amelynek bejelentkezési célközönsége a megadott Microsoft Entra-bérlő felhasználóira korlátozódik. Az {tenant} érték lehet a bérlő azonosítója GUID formátumban vagy a bérlőhöz társított tartománynév.
• https://login.microsoftonline.com/organizations/ – Ez a szolgáltató egy több-bérlős alkalmazást jelöl, amelynek bejelentkezési célközönsége bármely Microsoft Entra-bérlő felhasználói.

A szolgáltatói értékek nem tartalmazhatnak /common vagy /consumers azért, mert az IWA nem támogatja a személyes Microsoft-fiókokat (MSA).

Hozzájárulási követelmények

Mivel az IWA csendes folyamat:

• Az alkalmazás felhasználójának korábban hozzá kell adnia az alkalmazás használatához.

  VAGY

• A bérlői rendszergazdának korábban hozzá kell adnia, hogy a bérlő összes felhasználója használja az alkalmazást.

Mindkét követelmény teljesítéséhez az alábbi műveletek egyikét végre kell hajtani:

• Ön, mint alkalmazásfejlesztő a Grant lehetőséget választotta az Azure Portalon.
• A bérlői rendszergazda a(z) {tenant domain} rendszergazdai hozzájárulását választotta az alkalmazásregisztráció API-engedélyek lapján az Azure Portalon; lásd: Engedélyek hozzáadása a webes API eléréséhez.
• Ön megadta a módját, hogy a felhasználók hozzájáruljanak az alkalmazáshoz; lásd: Felhasználói hozzájárulás.
• Ön megadta a bérlői rendszergazda hozzájárulását az alkalmazáshoz; lásd: Rendszergazda istrator hozzájárulás.

A hozzájárulással kapcsolatos további információkért lásd: Engedélyek és hozzájárulás.

Következő lépés

Ismerje meg az ezekben a folyamatokban használt jogkivonatok beszerzését és gyorsítótárazását:

Jogkivonatok beszerzése és gyorsítótárazása a Microsoft Authentication Library (MSAL) használatával