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

  • Cikk

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 iparági szabványnak számító OAuth 2.0 vagy OpenID Connect 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 platformtól. A cikk segíthet az összetettebb feladatok megértésében, ezért érdemes elolvasni, mielőtt nekifog az alkalmazások létrehozásának.

Az Azure AD B2C-t használó összes alkalmazást regisztrálni kell a Azure AD B2C-bérlőben a 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.

A Azure AD B2C-nek küldött kérések egy felhasználói folyamatot (beépített szabályzatot) vagy egy egyéni szabályzatot határoznak meg, amely Azure AD B2C működését szabályozza. 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.

Az alkalmazások közötti interakció minden esetben hasonló felső szintű mintát követ:

  1. Az alkalmazás a 2.0-s verziójú végpontra irányítja a felhasználót egy szabályzat végrehajtásához.
  2. A felhasználó a szabályzat definíciója szerint teljesíti a szabályzat feltételeit.
  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 védett erőforrások eléréséhez.
  5. Az erőforrás-kiszolgáló ellenőrzi a biztonsági jogkivonatot, és megállapítja, hogy megadható-e hozzáférés.
  6. Az alkalmazás rendszeres időközönként frissíti a biztonsági jogkivonatot.

Ezek a lépések némileg 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 (beleértve a .NET-et, a PHP-t, a Java-t, a Rubyt, a Pythont és a Node.js), Azure AD a 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 felhasználói élményeket kezdeményez azáltal, hogy hitelesítési kéréseket küld Microsoft Entra azonosítónak. A kérés eredménye egy id_token. Ez a biztonsági jogkivonat tartalmazza a felhasználó identitását. Ezenfelül jogcímek formájában információkat nyújt a felhasználóról is:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

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

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 a Azure AD B2C-be, jelezve a végrehajtandó szabályzatot.
  3. A felhasználó végrehajtja a szabályzatot.
  4. Azure AD A B2C egy értéket ad vissza id_token a böngészőnek.
  5. A id_token ki van adva az átirányítási URI-nak.
  6. Az id_token érvényesítve van, és be van állítva egy munkamenet-cookie.
  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ő érvényesítése elegendő a felhasználó identitásának ellenőrzéséhez. Ez a folyamat egy munkamenet-cookie-t is beállít, amellyel azonosíthatja a felhasználót 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ások 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 is hozzá kell férnie egy háttérbeli webszolgáltatáshoz. Ebben az esetben a webalkalmazás egy kissé eltérő OpenID Connect-folyamatot hajthat végre, és engedélyezési kódok és frissítési jogkivonatok használatával szerezheti be a jogkivonatokat. Ezt a folyamatot a következő, Webes API-k című fejezet írja le.

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.

Azure AD A B2C két lehetőséget biztosít az egyoldalas alkalmazások bejelentkezésére és jogkivonatok lekérésére a háttérszolgáltatásokhoz vagy webes API-khoz való hozzáféréshez:

Engedélyezési kód folyamata (PKCE-vel)

Az OAuth 2.0 engedélyezési kódfolyama (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 hitelesített felhasználó és a védett API-k meghívásához szükséges Hozzáférési jogkivonatok megjelenítésére. Emellett a frissítési jogkivonatokat is visszaadja, 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 javasoljuk . A korlátozott élettartamú frissítési jogkivonatok segítenek az alkalmazásnak alkalmazkodni a modern böngésző cookie-k adatvédelmi korlátozásaihoz, például a Safari ITP-hez.

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

Egyoldalas alkalmazások hitelesítése

Implicit engedélyezési folyamat

Egyes kódtárak( például MSAL.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 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.

Ezt a megközelítést nem javasoljuk .

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

Webes API-k

A 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 biztosíthatják az adatok védelmét 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 a HTTP-kérés hitelesítési fejlécéhez:

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

Így a webes API a jogkivonat segítségével ellenőrizheti az API hívójának identitását, valamint a jogkivonatban kódolt jogcímek segítségével további információkhoz juthat a hívóról. Az Azure AD B2C-jogkivonatok referenciájából további információkat tudhat meg az alkalmazásban elérhető jogkivonatok és jogcímek különböző típusairól.

A webes API-k számos típusú ügyféltő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 szabályzatot, és a felhasználó elvégzi a felhasználói élményt.
  2. Azure AD A 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 az és az id_token engedélyezési kódot az átirányítási URI-nak.
  4. A webkiszolgáló ellenőrzi a id_token és beállít egy munkamenet-cookie-t.
  5. A webkiszolgáló az engedélyezési kód, az alkalmazásügyfél-azonosító és az ügyfél hitelesítő adatainak megadásával kéri Azure AD B2C-taccess_token.
  6. A access_token és refresh_token visszakerül a webkiszolgálóra.
  7. A webes API-t egy access_token engedélyezési fejlécben hívjuk meg.
  8. A webes API ellenőrzi a jogkivonatot.
  9. A rendszer biztonsági adatokat ad vissza a webalkalmazásnak.

Ha többet szeretne tudni a hitelesítési kódokról, frissítési jogkivonatokról, valamint a jogkivonatok lekérésének lépéseiről, olvasson az OAuth 2.0-protokollról.

Ha szeretné megtanulni, hogyan biztosíthat védelmet a webes API-k számára az Azure AD B2C segítségével, olvassa el a kezdeti lépéseket bemutató cikk webes API-kra vonatkozó oktatóanyagát.

Mobil és natív alkalmazások

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

Ebben a folyamatban az alkalmazás szabályzatokat hajt végre, és Microsoft Entra azonosítótól kap egy authorization_code azonosítót, miután a felhasználó befejezte a szabályzatot. Az authorization_code az alkalmazás engedélyét jelöli, amely lehetővé tette a háttérszolgáltatások meghívását az aktuálisan bejelentkezett felhasználó nevében. Az alkalmazás ezután lecserélheti a authorization_code háttérbeli értékeket egy access_token és egy refresh_tokenértékre. Az alkalmazás a access_token használatával hitelesítheti magát egy háttérbeli webes API-ban HTTP-kérésekben. Az refresh_token alkalmas ezenfelül új access_token kérésére is, ha a régi lejárna.

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

A hosszú ideig futó folyamatokat tartalmazó vagy a felhasználó jelenléte nélkül működő alkalmazásoknak is szükségük van a biztonságos erőforrások, például a webes API-k elérésének módjára. Ezek az alkalmazások az identitásukkal (a felhasználó delegált identitása helyett) és az OAuth 2.0 ügyfél hitelesítő adataival hitelesíthetik és lekérhetik a jogkivonatokat. Az ügyfél hitelesítő adatai nem egyeznek meg a nevében történő folyamattal, és a nevében történő folyamat nem használható kiszolgálóról kiszolgálóra történő hitelesítéshez.

A B2C Azure AD esetében az OAuth 2.0 ügyfél hitelesítő adatainak folyamata jelenleg nyilvános előzetes verzióban érhető el. Az ügyfél hitelesítő adatait azonban Microsoft Entra azonosító és a Microsoft Graph-alkalmazások vagy saját alkalmazás Microsoft Identitásplatform /token végpontja (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) használatával állíthatja be. További információért tekintse meg a Microsoft Entra tokenre vonatkozó referenciacikket.

Nem támogatott alkalmazástípusok

Webes API-láncok (meghatalmazásos folyamat)

Számos architektúrában szerepelnek olyan webes API-k, amelyek más, alsóbb rétegbeli webes API-kat hívnak meg, és mindkét API biztonságát az Azure AD B2C garantálja. Ez a forgatókönyv olyan natív ügyfeleknél fordul elő, amelyek webes API háttérrendszerrel rendelkeznek, és meghívnak egy Microsoft online szolgáltatást, például a Microsoft Graph API.

Ez a láncolatba fűzött webes API-megoldás az OAuth 2.0 JWT tulajdonosi hitelesítő adatok megadásával (vagy más néven a meghatalmazásos folyamat) segítségével valósítható meg. A nevében történő folyamat azonban jelenleg nincs implementálva a Azure AD B2C-ben.

Következő lépések

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