Hitelesítési folyamat támogatása a Microsoft Authentication Libraryben (MSAL)

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 környezet 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 hozzáférési engedély	A felhasználó bejelentkezik, és a felhasználó nevében hozzáférhet a webes API-khoz. Ne használja ezt a folyamatot – 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 az alkalmazás számára, hogy a felhasználó jelszavának közvetlen kezelésével jelentkezzen be. Ne használja ezt a folyamatot.	Asztali, mobil
Integrált Windows-hitelesítés (IWA)	Lehetővé teszi a tartományhoz 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) kizárólag munkaerőbérlők számára.	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ó token	Hozzáférési jogkivonat	Token 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 a tokenek interaktív és nem interaktív módon történő beszerzését.

• 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, lásd: 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. Engedélyezési kódot kér, amelyet beváltottak egy hozzáférési jogkivonatra.
2. A hozzáférési jogkivonat használatával egy webes API-t, a Microsoft Graphot hív meg.

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

• Az egyoldalas alkalmazásokhoz szükség van a Kódcsere Ellenőrzőkulcsra (PKCE), amikor az engedélyezési kód folyamát használják. 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ési folyamata lehetővé teszi egy webszolgáltatás (bizalmas ügyfél) számára, hogy saját hitelesítő adatait használja ahelyett, hogy egy felhasználót megszemélyesítene, és így hitelesítse magát 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. Azonosító token megszerzése alkalmazási titok vagy jelszó hitelesítő adatok segítségével
2. A tokent használja kérések benyújtására az erőforrás felé.

Diplomák

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

1. Token beszerzése tanúsítványos hitelesítő adatokkal
2. A tokent használja kérések benyújtására az erőforrás felé.

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 jogosultság

Az implicit engedélyezési folyamatot felváltotta a PKCE-vel kiegészített engedélyezési kód folyamat az ügyféloldali egyoldalas alkalmazások (SPA-k) előnyben részesített és biztonságosabb jogkivonat-engedélyezési folyamataként.

Figyelmeztetés

A továbbiakban nem ajánlott az implicit engedélyezési folyamat/menet használata. 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 Microsoft identitásplatformtól hozzáférési tokeneket kapjon a kiszolgálói hitelesítő adatok cseréje nélkül. Az implicit engedélyezési folyamat lehetővé teszi, hogy az alkalmazás bejelentkeztesse a felhasználót, fenntartson egy munkamenetet, és jogkivonatokat szerezzen be más web API-khoz a JavaScript-kódból, amelyet a böngésző letöltött és futtatott (általában webböngésző).

Implicit jogosultsági korlátozások

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-en keresztül kerülnek vissza a böngészőbe (ahol response_mode vagy query vagy fragment). Egyes böngészők korlátozzák az URL-cím hosszát a böngészősávban, és nem működnek, ha az túl hosszú. Í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 meghív egy szolgáltatást vagy webes API-t, amelynek egy másik szolgáltatást vagy webes API-t 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 újabb 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)

Az OAuth 2.0 erőforrás-tulajdonosi jelszóval való hitelesítés (ROPC) lehetővé teszi, hogy az alkalmazás a felhasználó jelszavának közvetlen kezelésével jelentkeztesse be a felhasználót. Az asztali alkalmazásban felhasználhatja a felhasználónév/jelszó folyamatot, hogy észrevétlenül szerezzen be egy jogkivonatot. Az alkalmazás használatakor nincs szükség felhasználói felületre.

Figyelmeztetés

A ROPC-folyamat elavult, használjon biztonságosabb folyamatot. Kövesse ezt az útmutatót a migrálási útmutatóhoz. A ROPC magas fokú megbízhatóságot és hitelesítő adatokat igényel. További információ: Mi a megoldás a jelszavak növekvő problémájára?

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

1. Token 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 hozzáférési token használatával

Ha észrevétlenül szeretne jogkivonatot beszerezni a Windows tartományhoz csatlakoztatott gépeken, javasoljuk az integrált Windows-hitelesítés (IWA) használatát az ROPC helyett. 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ényelne a felhasználó.

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

1. A token beszerzése integrált Windows-hitelesítéssel
2. A tokent használja kérések benyújtására az erőforrás felé.

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, ha VPN használata nélkül csatlakozik egy vállalati hálózathoz, és néha, ha VPN-en keresztül csatlakozik. Mivel az MFA konfigurációja és a kihívások gyakorisága fejlesztőként nem áll az irányítása alatt, az alkalmazásnak megfelelően kell kezelnie az IWA észrevétlen token beszerzésének meghiúsulását.

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

A nyilvános ügyfélalkalmazás létrehozásakor megadott jogosultságnak az alábbiak egyikének kell lennie:

• https://login.microsoftonline.com/{tenant}/ – Ez a hatóság egy 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 hatóság 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 áramlás.

• Az alkalmazás felhasználójának korábban bele kell egyeznie az alkalmazás használatába.

  VAGY

• A bérlői rendszergazdának korábban hozzá kell járulnia, hogy a bérlet összes felhasználója használhassa 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 Rendszergazdai hozzájárulás megadása/visszavonása elemet választotta az alkalmazásregisztráció API-engedélyek lapján az Azure portálon; lásd: Engedélyek hozzáadása a saját 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: Rendszergazdai 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árba helyezését.

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