Az Active Directory B2C-ben használható alkalmazástípusok

Fontos

2025. május 1-jére az Azure AD B2C már nem lesz elérhető az új ügyfelek számára. További információ a GYIK-ben.

Az Azure Active Directory B2C (Azure AD B2C) támogatja a különböző modern alkalmazásarchitektúrák hitelesítését. Ezek mindegyike az OAuth 2.0 vagy az OpenID Connect iparági szabvány protokollon alapul. Ez a cikk azokat az alkalmazástípusokat ismerteti, amelyeket létrehozhat, függetlenül a kívánt nyelvétől vagy platformától. Emellett segít megérteni a magas szintű forgatókönyveket, mielőtt elkezdené az alkalmazások létrehozását.

Az Azure AD B2C-t használó összes alkalmazást regisztrálni kell az Azure AD B2C-bérlőben az Azure Portal használatával. Az alkalmazásregisztrációs folyamat összegyűjti és hozzárendeli az értékeket, például:

• Alkalmazásazonosító, amely egyedileg azonosítja az alkalmazást.
• Válasz URL-cím, amellyel vissza lehet irányítani a válaszokat az alkalmazásba.

Az Azure AD B2C-nek küldött összes kérés egy felhasználói folyamatot (egy beépített szabályzatot) vagy egy egyéni szabályzatot határoz meg, amely az Azure AD B2C viselkedését vezérli. Mindkét szabályzattípus lehetővé teszi a felhasználói élmények nagy mértékben testre szabható készletének létrehozását.

Minden alkalmazás interakciója hasonló, magas szintű mintát követ:

1. Az alkalmazás átirányítja a felhasználót a 2.0-s verziójú végpontra egy szabályzat végrehajtásához.
2. A felhasználó a szabályzat definíciója szerint végzi el a szabályzatot.
3. Az alkalmazás egy biztonsági jogkivonatot kap a 2.0-s verziójú végponttól.
4. Az alkalmazás a biztonsági jogkivonatot használja a védett információk vagy egy védett erőforrás eléréséhez.
5. Az erőforrás-kiszolgáló ellenőrzi a biztonsági jogkivonatot annak ellenőrzéséhez, hogy biztosítható-e a hozzáférés.
6. Az alkalmazás rendszeresen frissíti a biztonsági tokent.

Ezek a lépések kissé eltérhetnek az éppen létrehozott alkalmazás típusától függően.

Webalkalmazások

A webkiszolgálón üzemeltetett és böngészőn keresztül elérhető webalkalmazások (például .NET, PHP, Java, Ruby, Python és Node.js) esetében az Azure AD B2C minden felhasználói élményhez támogatja az OpenID Connectet . Az OpenID Connect Azure AD B2C-implementációjában a webalkalmazás a Microsoft Entra ID-nak küldött hitelesítési kérelmek kiadásával felhasználói élményt kezdeményez. A kérés eredménye egy id_token. Ez a biztonsági jogkivonat a felhasználó azonosítóját reprezentálja. Emellett jogcímek formájában nyújt információkat a felhasználóról:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

Az Azure AD B2C-jogkivonatok referenciájában további információ az alkalmazások számára elérhető jogkivonatok és jogcímek típusairól.

Egy webalkalmazásban a szabályzatok minden végrehajtása az alábbi magas szintű lépéseket hajtja végre:

1. A felhasználó megkeresi a webalkalmazást.
2. A webalkalmazás átirányítja a felhasználót az Azure AD B2C-be, jelezve a végrehajtandó szabályzatot.
3. A felhasználó kitölti a szabályzatot.
4. Az Azure AD B2C egy értéket ad vissza id_token a böngészőnek.
5. A id_token az átirányítási URI-hoz van elküldve.
6. A id_token érvényesítve van, és beállítanak egy munkamenet-cookie-t.
7. A rendszer egy biztonságos lapot ad vissza a felhasználónak.

id_token A Microsoft Entra-azonosítótól kapott nyilvános aláírókulcs használatával történő ellenőrzés elegendő a felhasználó személyazonosságának ellenőrzéséhez. Ez a folyamat egy munkamenet-cookie-t is beállít, amely a felhasználó azonosítására használható a későbbi oldalkérések során.

Ha működés közben szeretné megtekinteni ezt a forgatókönyvet, próbálkozzon a webalkalmazás bejelentkezési kódmintáinak egyikével az Első lépések szakaszban.

Az egyszerű bejelentkezés megkönnyítése mellett előfordulhat, hogy egy webalkalmazásnak hozzá kell férnie egy háttérbeli webszolgáltatáshoz is. Ebben az esetben a webalkalmazás egy kissé eltérő OpenID Connect-folyamatot hajthat végre, és engedélyezési kódok és jogkivonatok frissítésével szerezheti be a jogkivonatokat. Ez a forgatókönyv a következő webes API-k szakaszban látható.

Egyoldalas alkalmazások

Számos modern webalkalmazás ügyféloldali egyoldalas alkalmazásként (SPA- k) épülnek fel. A fejlesztők JavaScript vagy SPA-keretrendszer, például Angular, Vue vagy React használatával írják meg őket. Ezek az alkalmazások webböngészőben futnak, és eltérő hitelesítési jellemzőkkel rendelkeznek, mint a hagyományos kiszolgálóoldali webalkalmazások.

Az Azure AD B2C két lehetőséget biztosít arra, hogy az egyoldalas alkalmazások bejelentkezhessenek a felhasználókba, és jogkivonatokat szerezzenek be a háttérszolgáltatásokhoz vagy webes API-khoz való hozzáféréshez:

Engedélyezési kódfolyamat (PKCE-vel)

Az OAuth 2.0 engedélyezési kódfolyamat (PKCE-vel) lehetővé teszi az alkalmazás számára, hogy az azonosító jogkivonatokra vonatkozó engedélyezési kódot cseréljen a védett API-k meghívásához szükséges hitelesített felhasználó- és Hozzáférési jogkivonatok megjelenítésére. Emellett olyan frissítési jogkivonatokat is visszaad, amelyek hosszú távú hozzáférést biztosítanak az erőforrásokhoz a felhasználók nevében anélkül, hogy interakcióra lenne szükség a felhasználókkal.

Ezt a megközelítést ajánlottuk . A korlátozott élettartamú frissítési jogkivonatok segítenek az alkalmazásnak alkalmazkodni a modern böngésző cookie-k adatvédelmi korlátaihoz, például a Safari ITP-hez.

A folyamat előnyeinek kihasználásához az alkalmazás használhat egy olyan hitelesítési kódtárat, amely támogatja azt, például aMSAL.js 2.x-et.

Implicit jogosultságkezelési folyamat

Egyes kódtárak, például azMSAL.js 1.x, csak az implicit engedélyezési folyamatot támogatják, vagy az alkalmazás implicit folyamat használatára van implementálva. Ezekben az esetekben az Azure AD B2C támogatja az OAuth 2.0 implicit folyamatot. Az implicit engedélyezési folyamat lehetővé teszi az alkalmazás számára az azonosítók és az Access-jogkivonatok lekérését. Az engedélyezési kód folyamatától eltérően az implicit engedélyezési folyamat nem ad vissza frissítési jogkivonatot.

Ez a hitelesítési folyamat nem tartalmaz olyan alkalmazásforgatókönyveket, amelyek platformfüggetlen JavaScript-keretrendszereket használnak, például az Electront és a React-Native-t. Ezek a forgatókönyvek további képességeket igényelnek a natív platformokkal való interakcióhoz.

Figyelmeztetés

A Microsoft azt javasolja, hogy ne használja az implicit engedélyezési folyamatot. Az SLA-k támogatásának ajánlott módja az OAuth 2.0 engedélyezési kódfolyamat (PKCE-vel). A folyamat bizonyos konfigurációihoz nagyon nagy megbízhatóságra van szükség az alkalmazásban, és olyan kockázatokat hordoz, amelyek más folyamatokban nincsenek jelen. Ezt a folyamatot csak akkor érdemes használni, ha más biztonságosabb folyamatok nem életképesek. További információkért tekintse meg az implicit engedélyezési folyamattal kapcsolatos biztonsági problémákat.

Webes API-k

Az Azure AD B2C használatával biztonságossá teheti a webszolgáltatásokat, például az alkalmazás RESTful webes API-ját. A webes API-k az OAuth 2.0 használatával biztonságossá tehetik adataikat a bejövő HTTP-kérések jogkivonatokkal történő hitelesítésével. A webes API hívója hozzáfűz egy jogkivonatot egy HTTP-kérés engedélyezési fejlécéhez:

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
Accept: application/json
...

A webes API ezután a jogkivonat használatával ellenőrizheti az API-hívó identitását, és kinyerheti a hívó adatait a jogkivonatban kódolt jogcímekből. Az Azure AD B2C-tokenreferenciában további információ az alkalmazások számára elérhető jogkivonatok és jogcímek típusairól.

A webes API-k számos ügyféltípusból fogadhatnak jogkivonatokat, beleértve a webalkalmazásokat, az asztali és mobilalkalmazásokat, az egyoldalas alkalmazásokat, a kiszolgálóoldali démonokat és más webes API-kat. Íme egy példa egy webes API-t meghívó webalkalmazás teljes folyamatára:

1. A webalkalmazás végrehajt egy irányelvet, és a felhasználó megéli a felhasználói élményt.
2. Az Azure AD B2C egy (OpenID Connect) id_token és egy engedélyezési kódot ad vissza a böngészőnek.
3. A böngésző közzéteszi a id_token és az engedélyezési kódot az átirányítási URI-nak.
4. A webkiszolgáló ellenőrzi a id_token munkamenet-cookie-t, és beállít egy munkamenet-cookie-t.
5. A webkiszolgáló az Azure AD B2C-től kér egy access_token, megadva az engedélyezési kódot, az alkalmazás ügyfél-azonosítóját és az ügyfél hitelesítő adatait.
6. A access_token és a refresh_token visszaadásra kerül a webkiszolgálónak.
7. A webes API meghívása egy access_token engedélyezési fejlécben történik.
8. A webes API ellenőrzi a jogkivonatot.
9. A biztonságos adatok visszakerülnek a webalkalmazásba.

Ha többet szeretne megtudni az engedélyezési kódokról, a jogkivonatok frissítéséről és a jogkivonatok beszerzésének lépéseiről, olvassa el az OAuth 2.0 protokollt.

Ha szeretné megtudni, hogyan védheti meg a webes API-t az Azure AD B2C használatával, tekintse meg a webes API-oktatóanyagokat az Első lépések szakaszban.

Mobil- és natív alkalmazások

Az eszközökre, például mobil- és asztali alkalmazásokra telepített alkalmazásoknak gyakran a felhasználók nevében kell hozzáférnie a háttérszolgáltatásokhoz vagy a webes API-khoz. Az Azure AD B2C és az OAuth 2.0 engedélyezési kódfolyamat használatával testre szabott identitáskezelési funkciókat adhat a natív alkalmazásokhoz, és biztonságosan hívhatja meg a háttérszolgáltatásokat.

Ebben a folyamatban az alkalmazás végrehajtja a szabályzatokat, és a felhasználó a szabályzat teljesítése után egy authorization_code-et kap a Microsoft Entra ID-tól. A authorization_code az alkalmazás azon jogosultságát jelenti, hogy a jelenleg bejelentkezett felhasználó nevében hívjon meg háttérszolgáltatásokat. Az alkalmazás ezután kicserélheti a authorization_code háttérben egy és egy access_tokenrefresh_token. Az alkalmazás a access_token használhatja a HTTP kérésekben egy háttérwebes API hitelesítésére. Használhatja a refresh_token-t is, hogy új access_token-t szerezzen, amikor egy régebbi lejár.

Démonok/kiszolgálóoldali alkalmazások

A hosszú ideig futó folyamatokat tartalmazó vagy felhasználó jelenléte nélkül működő alkalmazásoknak is szükségük van egy olyan módszerre, amellyel biztonságos erőforrásokhoz, például webes API-khoz lehet hozzáférni. Ezek az alkalmazások az identitásukkal (a felhasználó delegált identitása helyett) és az OAuth 2.0 ügyfél hitelesítő folyamatával hitelesíthetik magukat és szerezhetik meg a jogkivonatokat. Az ügyfél-hitelesítési folyamat nem ugyanaz, mint az on-behalf-flow, és az on-behalf-flow nem alkalmas szerver-szerver hitelesítéshez.

Az Azure AD B2C esetében az OAuth 2.0 ügyfél hitelesítő adatainak folyamata jelenleg nyilvános előzetes verzióban érhető el. Beállíthatja azonban az ügyfél hitelesítési folyamot a Microsoft Entra ID és a Microsoft identity platform /token végpontja (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) használatával egy Microsoft Graph-alkalmazáshoz vagy saját alkalmazásához. További információkért tekintse meg a Microsoft Entra-jogkivonatok referenciacikkét .

Nem támogatott alkalmazástípusok

Webes API-láncok (a folyamat nevében)

Számos architektúra tartalmaz egy webes API-t, amelynek egy másik alsóbb rétegbeli webes API-t kell meghívnia, ahol mindkettőt az Azure AD B2C védi. Ez a forgatókönyv olyan natív ügyfeleknél fordul elő, amelyek webes API háttérrendszerrel rendelkeznek, és egy Microsoft online szolgáltatást, például a Microsoft Graph API-t hívnak meg.

Ez a láncolt webes API forgatókönyv támogatott az OAuth 2.0 JWT jogosítvány engedélyező segítségével, amit más néven a valaki nevében történő folyamatnak is neveznek. Az on-behalf-of flow azonban jelenleg nincs implementálva az Azure AD B2C-ben.

Következő lépések

További információ a felhasználói folyamatok által az Azure Active Directory B2C-ben biztosított beépített szabályzatokról.