Az MSAL által 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 a különböző alkalmazástípusok és forgatókönyvek általi használathoz.

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	Hozzáférés a webes API-khoz magának az alkalmazásnak az identitásával. Általában a kiszolgálók közötti kommunikációhoz és a felhasználói beavatkozást nem igénylő automatizált szkriptekhez használatos.	Daemon
Eszközkód	A felhasználó bejelentkezése és a webes API-khoz való hozzáférés a felhasználó nevében a bemenet által korlátozott eszközökön, például az intelligens tv-ken és az eszközök internetes hálózatán (IoT) található eszközökön. Parancssori felületi (CLI-) alkalmazások is használják.	Asztali, mobil
Implicit engedélyezés	Felhasználói bejelentkezés és webes API-khoz való hozzáférés a felhasználó nevében. Az implicit engedélyezési folyamat már nem ajánlott – használja helyette az engedélyezési kódot a Kódcsere (PKCE) ellenőrző kulcsával.	* Egyoldalas alkalmazás (SPA) * Web
A nevében (OBO)	Hozzáférés egy "felsőbb rétegbeli" webes API-ból egy "lefelé irányuló" 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 lesznek átadva az alsóbb rétegbeli API-nak.	Webes API
Felhasználónév/jelszó (ROPC)	Lehetővé teszi, hogy az alkalmazások közvetlenül a jelszavuk kezelésével jelentkezzenek be a felhasználóba. Az ROPC-folyamat HASZNÁLATA NEM ajánlott.	Asztali, mobil
Integrált Windows-hitelesítés (IWA)	Lehetővé teszi, hogy a tartományon vagy Microsoft Entra ID csatlakoztatott számítógépeken lévő alkalmazások csendesen szerezzenek be egy jogkivonatot (a felhasználó felhasználói beavatkozása nélkül).	Asztali, mobil

Tokenek

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

Hitelesítési folyamat vagy művelet	Megköveteli	Azonosító jogkivonata	Hozzáférési jogkivonat	Jogkivonat frissítése	Engedélyezési kód
Engedélyezési kód folyamata		✅	✅	✅	✅
Ü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 frissítésének beváltása	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ér bemenetet a felhasználótól. Más néven csendes jogkivonat-beszerzés, az alkalmazás egy olyan metódussal próbál jogkivonatot lekérni, amelyben előfordulhat, hogy az engedélyezési kiszolgáló nem kér bemenetet a felhasználótól.

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 sikertelen. 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 a 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őkulcsára van szükség 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 a hozzáférési jogkivonatot csak egyszer váltsa be engedélyezési kóddal.

  Ha többször próbál meg hozzáférési jogkivonatot beszerezni ugyanazzal az engedélyezési kóddal, az alábbihoz hasonló hibát ad vissza a Microsoft Identitásplatform. 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, hogy egy alkalmazás identitásával hozzáférjen a webes erőforrásokhoz. 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ó azonnali interakciót végezna. Ezeket az alkalmazástípusokat gyakran démonoknak vagy szolgáltatásoknak nevezik.

Az ügyfél-hitelesítő adatok engedélyezési folyamata lehetővé teszi, hogy egy webszolgáltatás (egy 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 hívásakor. Ebben a forgatókönyvben az ügyfél általában egy középső rétegbeli 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 a hívó szolgáltatás számára, hogy hitelesítő adatként tanúsítványt (közös titkos kód helyett) használjon.

Alkalmazás titkos kódjai

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

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

Tanúsítványok

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

1. Jogkivonatot szerez be tanúsítvány hitelesítő adataival.
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 Azure AD.
• A bizalmas ügyfélalkalmazás objektumának a kódban való létrehozásakor lett átadva.

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

A bizalmas ügyfélfolyamat nem támogatott az olyan mobilplatformokon, mint az Android, az iOS vagy a 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ód-folyamata lehetővé teszi, hogy a felhasználók bejelentkezhessenek a bemeneti korlátozásokkal rendelkező eszközökbe, például az intelligens tévékbe, az IoT-eszközökbe és a nyomtatókba. A Microsoft Entra ID interaktív hitelesítéséhez 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 interaktív bejelentkezését.

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 egy kódot biztosít, é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ím felkereséséhez (például https://microsoft.com/devicelogin). Ezután a rendszer felkéri a felhasználót, hogy adja meg a kódot, és normál hitelesítési felületen haladjon 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. A sikeres hitelesítést követően 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ódra vonatkozó korlátozások

• 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}/, ahol {tenant} a bérlőazonosítót képviselő GUID vagy a bérlőhöz társított tartománynév található.
  • Munkahelyi és iskolai fiókok: https://login.microsoftonline.com/organizations/.

Implicit támogatás

Az implicit engedélyt felváltotta az engedélyezési kód folyamata, és a PKCE lett az ügyféloldali egyoldalas alkalmazások (SPA-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ódfolyamot a PKCE-vel.

A JavaScriptben írt egyoldalas webalkalmazások (beleértve a keretrendszereket, például 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, eltérő biztonsági jellemzőkkel rendelkeznek, mint a hagyományos kiszolgálóoldali webalkalmazások. Mielőtt az engedélyezési kódfolyamhoz rendelkezésre állt a Proof Key for Code Exchange (PKCE), az implicit engedélyezési folyamatot az SLA-k használták a hozzáférési jogkivonatok jobb válaszképessége és hatékonysága érdekében.

Az OAuth 2 implicit engedélyezési folyamata lehetővé teszi, hogy az alkalmazás hozzáférési jogkivonatokat kapjon a Microsoft Identitásplatform anélkül, hogy háttérkiszolgálói hitelesítőadat-cserét hajtanak végre. Az implicit engedélyezési folyamat lehetővé teszi, hogy az alkalmazás bejelentkezjen a felhasználóba, fenntartson egy munkamenetet, és jogkivonatokat szerezzen be más webes API-khoz a felhasználóü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, például electron vagy React Native. Az ilyen platformfüggetlen keretrendszerek további képességeket igényelnek az általuk futtatott natív asztali és mobilplatformokkal való interakcióhoz.

Az implicit folyamat móddal kibocsátott jogkivonatok hossza korlátozott, mert a rendszer visszaadja őket a böngészőnek az URL-címben (ahol response_mode vagy fragment).query Egyes böngészők korlátozzák az URL-cím hosszát a böngészősávon, és túl hosszú idő esetén meghiúsulnak. Így ezek az implicit folyamatjogkivonatok nem tartalmaznak groups vagy wids jogcímeket.

Nevében (OBO)

Az OAuth 2 nevében történő 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, biztonságossá kell tennie egy hozzáférési jogkivonatot a Microsoft Identitásplatform a kérelmező felhasználó nevében.

A fenti diagram elemei:

1. Az alkalmazás hozzáférési jogkivonatot szerez be a webes API-hoz.
2. Egy ügyfél (webes, asztali, mobil vagy egyoldalas alkalmazás) egy védett webes API-t hív meg, é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ívja meg az alsóbb rétegbeli webes API-t a felhasználó nevében. A webes API később más alsóbb rétegbeli API-khoz is kérhet jogkivonatokat (de továbbra is 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. Az ROPC magas szintű megbízhatóságot és hitelesítő adatoknak való kitettséget igényel. Csak akkor használja az ROPC-t, ha egy biztonságosabb folyamat nem használható. További információ: Mi a megoldás a jelszavak egyre növekvő problémájára?

Az OAuth 2 erőforrás-tulajdonosi jelszó hitelesítő adatainak (ROPC) megadása lehetővé teszi, 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 csendesen 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 el kell kerülnie, 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. Jogkivonatot szerez be úgy, hogy elküldi a felhasználónevet és a jelszót az identitásszolgáltatónak.
2. Meghív egy webes API-t 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 . Egyéb forgatókönyvek esetén használja az eszköz kódfolyamatát.

Az ROPC korlátozásai

Az 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ó.
• Az 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 helyi fiókok esetében támogatott Microsoft Entra Külső ID.
  • További információ a ROPC-ról MSAL.NET és Microsoft Entra Külső ID: Erőforrás-tulajdonosi jelszó hitelesítő adatai (ROPC) B2C-vel.

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

Megjegyzés

Az integrált Windows-hitelesítést felváltotta a jogkivonatok csendes lekérésének megbízhatóbb módja – WAM. A WAM csendesen bejelentkezhet 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 megpróbál lekérni az aktuális Windows-felhasználó jogkivonatának lekéréséhez, beleértve az IWA-t és a PRT beváltásá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 ID csatlakoztatott Windows-számítógépeken futó asztali és mobilalkalmazásokhoz. Az IWA használatával ezek az alkalmazások csendesen szereznek be egy jogkivonatot anélkül, hogy felhasználói felületi interakciót kellene megkövetelni a felhasználótól.

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

1. Jogkivonatot szerez be integrált Windows-hitelesítéssel.
2. A jogkivonat használatával erőforrás-kéréseket készít.

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 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. A közvetlenül Microsoft Entra ID Active Directory-háttérszolgáltatás nélkül létrehozott felhasználók (felügyelt felhasználók) nem használhatják ezt a hitelesítési folyamatot.
• 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 Microsoft Entra ID MFA-kihívást állít ki. Ha az IWA meghibásodik, vissza kell esnie egy interaktív hitelesítési módszerre a korábban leírtak szerint. Microsoft Entra ID AI használatával határozza meg, hogy mikor van szükség kétfaktoros 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 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 a következők 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 ID 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 ID bérlő felhasználói.
• Személyes fiókok. 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 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 el kell végezni:
  • Ön, mint alkalmazásfejlesztő kiválasztotta a Grant lehetőséget az Azure Portalon.
  • A bérlői rendszergazda a(z) {tenant domain} rendszergazdai hozzájárulásának megadása/visszavonása lehetőséget választotta az alkalmazásregisztráció API-engedélyek lapján a Azure Portal; lásd: Engedélyek hozzáadása a webes API eléréséhez.
  • Ön módot adott a felhasználóknak, hogy hozzájáruljanak az alkalmazáshoz; lásd: Az engedélyek és hozzájárulások áttekintése a Microsoft Identitásplatform.
  • Ön 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ése a Microsoft Identitásplatform.

Következő lépések

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