Az MSAL-ben támogatott hitelesítési folyamatok

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ér 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 a bemeneti korlátozásokkal rendelkező eszközökön, például az intelligens tévékben és az IoT-eszközökön. 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 helyette az engedélyezési kódot a Code Exchange-hez (PKCE) tartozó Proof Key használatával.	* 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-azonosítóhoz csatlakoztatott számítógépeken lévő 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	Jogkivonat frissítése	✅	✅	✅

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 a bejelentkezéshez, a többtényezős hitelesítéshez (MFA) vagy a több erőforrás-hozzáférési engedélyhez való hozzájárulás megadásához.
• Nem interaktív – Előfordulhat, hogy a rendszer nem kéri a felhasználótól a bemenetet. Más néven csendes jogkivonat-beszerzés, az alkalmazás egy olyan módszerrel próbál jogkivonatot lekérni, amelyben előfordulhat, hogy az engedélyezési kiszolgáló 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 előző ábrán az alkalmazás:

1. Egy 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, például 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ója megköveteli, hogy egy engedélyezési kóddal csak egyszer váltson be hozzáférési jogkivonatot.

  Ha többször próbál meg 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. Ne feledje, hogy 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 ügyfél hitelesítő adatainak folyamata lehetővé teszi a webes erőforrások elérését egy alkalmazás identitásának használatával. Ezt a fajta engedélyezést gyakran használják a kiszolgálók közötti (S2S) interakciókhoz, amelyeknek a háttérben kell futniuk anélkül, hogy a felhasználó azonnal interakcióba lép. Ezeket az alkalmazástípusokat gyakran démonoknak vagy szolgáltatásoknak 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 előző ábrán az alkalmazás:

1. Jogkivonatot szerez be egy alkalmazás titkos kód vagy jelszó hitelesítő adataival.
2. A jogkivonat használatával erőforrás-kérelmeket kezdeményezhet.

Diplomák

Az előző ábrán az alkalmazás:

1. Tanúsítvány hitelesítő adataival szerez be jogkivonatot.
2. A jogkivonat használatával erőforrás-kérelmeket kezdeményezhet.

Az ilyen típusú ügyfél-hitelesítő adatoknak a következőknek kell lenniük:

• Regisztrálva az Azure AD-ben.
• A kódban lévő bizalmas ügyfélalkalmazás-objektum létrehozásakor átadott.

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

A bizalmas ügyfélfolyamat nem támogatott mobilplatformokon, például Android, iOS vagy Univerzális Windows-platform (UWP). A mobilalkalmazások olyan nyilvános ügyfélalkalmazások, amelyek nem garantálják a hitelesítési titkos kódok titkosságát.

Eszközkód

Az OAuth 2 eszközkódfolyamat lehetővé teszi, hogy a felhasználók bejelentkezhessenek a bemeneti korlátozásokkal rendelkező eszközökre, például az intelligens tévékbe, az eszközök internetes hálózatára (IoT) és a 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 egy másik eszköz, például egy számítógép vagy mobiltelefon használatát, hogy 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.

A fenti diagram elemei:

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). Ezután a rendszer kéri a felhasználót, hogy adja meg a kódot, és normál hitelesítési felületen halad tovább, beleértve a hozzájárulási kéréseket és a többtényezős hitelesítést, ha szükséges.
2. Sikeres hitelesítés esetén a kérelmező alkalmazás megkapja a szükséges jogkivonatokat a Microsoft Identitásplatform, és azokat használja a szükséges webes API-hívások végrehajtásához.

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őalapú: https://login.microsoftonline.com/{tenant}/, hol {tenant} található a bérlőazonosítót képviselő GUID 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ést 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. 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 implicit engedélyezési folyamat lehetővé teszi, hogy az alkalmazás a háttérkiszolgáló hitelesítő adatainak cseréje nélkül szerezze be 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 az URL-címben visszakerülnek 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 on-behalf-of hitelesítési folyamat akkor használatos, ha egy alkalmazás olyan szolgáltatást vagy webes API-t hív meg, amely viszont egy delegált felhasználói identitással és engedélyekkel meghív egy másik szolgáltatást vagy webes API-t, amelyet a kérelemláncon keresztül kell propagálni. 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 kérelmező felhasználó nevében.

A fenti diagram elemei:

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 ezzel a jogkivonattal hív meg egy alsóbb rétegbeli webes API-t 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-tulajdonosi jelszó hitelesítő adatainak (ROPC) folyamata már 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 erőforrás-tulajdonosi jelszó hitelesítő adatai (ROPC) lehetővé teszik, hogy az alkalmazás közvetlenül a jelszó kezelésével 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, amelyben interaktív felhasználói felületet biztosít a felhasználói bejelentkezéshez.

Az előző á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-t hív meg a jogkivonat használatával.

Ha csendesen szeretne jogkivonatot beszerezni a Windows tartományhoz csatlakoztatott gépeken, javasoljuk, hogy ROPC helyett a Web Account Managert (WAM) használja. 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 .NET-alkalmazásokban.
• A ROPC nem támogatott Univerzális Windows-platform (UWP) alkalmazásokban.
• A ROPC csak a helyi fiókok esetében támogatott Microsoft Entra Külső ID.
  • A ROPC-ról az MSAL.NET és Microsoft Entra Külső ID a B2C-vel rendelkező erőforrás-tulajdonosi jelszó hitelesítő adataival (ROPC) kapcsolatos információkért lásd.

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

Feljegyzés

Az integrált Windows-hitelesítést a jogkivonatok csendes lekérésének megbízhatóbb módjára cserélték – WAM. A WAM csendesen be tud jelentkezni az aktuális windowsos felhasználóba. Ez a munkafolyamat nem igényel összetett beállítást, és még a személyes (Microsoft-) fiókok esetében is működik. A Windows Broker (WAM) belsőleg több stratégiát is kipróbál, hogy jogkivonatot kapjon az aktuális Windows-felhasználóhoz, beleértve az IWA-t és beváltsa a PRT-t. Ez kiküszöböli az IWA-val kapcsolatos korlátozások többségét.

Az MSAL támogatja az integrált Windows-hitelesítést (IWA) a tartományhoz csatlakoztatott vagy Microsoft Entra azonosítóhoz 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 előző ábrán az alkalmazás:

1. Jogkivonat beszerzése integrált Windows-hitelesítéssel.
2. A jogkivonat használatával erőforrás-kérelmeket kezdeményezhet.

Az IWA korlátozásai

• Kompatibilitás. Az integrált Windows-hitelesítés (IWA) engedélyezve van a .NET asztali, .NET- és Univerzális Windows-platform (UWP) alkalmazásokhoz. Az IWA csak az ADFS á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 ID-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 jogkivonatok beszerzésének sikertelenségé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-azonosítójú 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-azonosítójú bérlő felhasználói.
• Személyes fiókok. A szolgáltatói értékek nem tartalmazhatnak /common vagy /consumers mert a személyes Microsoft-fiókokat (MSA) az IWA nem támogatja.
• 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 a bérlő összes felhasználójának az alkalmazás használatához. 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 az engedélyek és hozzájárulások áttekintését a Microsoft Identitásplatform.
  • Megadta a bérlői rendszergazda számára, hogy hozzájáruljon az alkalmazáshoz; lásd az engedélyek és hozzájárulások áttekintését a Microsoft Identitásplatform.

Következő lépések

Most, hogy áttekintette az MSAL által támogatott hitelesítési folyamatokat, megismerheti az ezekben a folyamatokban használt jogkivonatok beszerzését és gyorsítótárazását.