Miért érdemes Microsoft Identitásplatformra (a 2.0-s verzióra) frissíteni?

  • Cikk

Új alkalmazás fejlesztésekor fontos tisztában lennie a Microsoft Identitásplatform (2.0-s verzió) és az Azure Active Directory-végpontok (1.0-s verzió) közötti különbségekkel. Ez a cikk a végpontok közötti fő különbségeket és a Microsoft Identitásplatform néhány meglévő korlátozását ismerteti.

Ki jelentkezhet be?

Ki tud bejelentkezni az 1.0-s és a 2.0-s verziójú végpontokkal?

  • Az 1.0-s verziójú végpont csak a munkahelyi és iskolai fiókoknak engedélyezi az alkalmazásba való bejelentkezést (Azure AD)
  • A Microsoft Identitásplatform végpont lehetővé teszi, hogy a munkahelyi és iskolai fiókok Microsoft Entra azonosítóból és személyes Microsoft-fiókokból (MSA), például hotmail.com, outlook.com és msn.com jelentkezzenek be.
  • Mindkét végpont egy Microsoft Entra-címtár vendégfelhasználóinak bejelentkezését is fogadja az egybérlősként konfigurált alkalmazásokhoz vagy a bérlőspecifikus végpontrahttps://login.microsoftonline.com/{TenantId_or_Name} () konfigurált több-bérlős alkalmazásokhoz.

A Microsoft Identitásplatform végpont lehetővé teszi olyan alkalmazások írását, amelyek elfogadják a személyes Microsoft-fiókokból, valamint a munkahelyi és iskolai fiókokból érkező bejelentkezéseket. Ez lehetővé teszi, hogy teljesen fiókfüggetlenül írja meg az alkalmazást. Ha például az alkalmazás meghívja a Microsoft Graphot, néhány további funkció és adat elérhetővé válik a munkahelyi fiókok számára, például a SharePoint-webhelyek vagy a címtáradatok számára. Számos művelet, például a felhasználó e-mailjeinek olvasása esetén azonban ugyanaz a kód elérheti az e-maileket a személyes és a munkahelyi és iskolai fiókokhoz is.

Microsoft Identitásplatform végponthoz a Microsoft Authentication Library (MSAL) használatával férhet hozzá a fogyasztói, oktatási és nagyvállalati világokhoz. A Azure AD 1.0-s verziójú végpont csak munkahelyi és iskolai fiókokból fogad bejelentkezéseket.

Az Azure AD 1.0-s verziójú végpontot használó alkalmazásoknak előre meg kell adniuk a szükséges OAuth 2.0-engedélyeket, például:

Példa az Engedélyregisztrációs felhasználói felületre

A közvetlenül az alkalmazásregisztráción beállított engedélyek statikusak. Bár a Azure Portal definiált alkalmazás statikus engedélyei szépek és egyszerűek maradnak, néhány lehetséges problémát jelez a fejlesztők számára:

  • Az alkalmazásnak minden szükséges engedélyt le kell kérnie a felhasználó első bejelentkezésekor. Ez az engedélyek hosszú listáját eredményezheti, amely megakadályozza, hogy a végfelhasználók jóváhagyják az alkalmazás hozzáférését a kezdeti bejelentkezéskor.

  • Az alkalmazásnak ismernie kell azokat az erőforrásokat, amelyekhez előre hozzáférhet. Nehéz volt olyan alkalmazásokat létrehozni, amelyek tetszőleges számú erőforráshoz fértek hozzá.

A Microsoft Identitásplatform végponttal figyelmen kívül hagyhatja az alkalmazásregisztrációs információkban meghatározott statikus engedélyeket a Azure Portal, és növekményesen kérhet engedélyeket, ami azt jelenti, hogy az engedélyek minimális készletének előzetes megadását kéri, és idővel tovább növekszik, mivel az ügyfél további alkalmazásfunkciókat használ. Ehhez bármikor megadhatja az alkalmazás által igényelt hatóköröket úgy, hogy a hozzáférési jogkivonat kérésekor az új hatóköröket bele kell venni a scope paraméterbe anélkül, hogy előre meg kellene határozni őket az alkalmazásregisztrációs adatokban. Ha a felhasználó még nem járult hozzá a kérelemhez hozzáadott új hatókörökhöz, a rendszer csak az új engedélyekhez való hozzájárulást kéri. További információ: engedélyek, hozzájárulás és hatókörök.

Ha lehetővé teszi egy alkalmazás számára, hogy dinamikusan kérjen engedélyeket a scope paraméteren keresztül, teljes körű vezérlést biztosít a fejlesztők számára a felhasználói élmény felett. Emellett betöltheti a hozzájárulási felületet, és egyetlen kezdeti engedélyezési kérelemben kérheti az összes engedélyt. Ha az alkalmazásnak nagy számú engedélyre van szüksége, ezeket az engedélyeket növekményesen gyűjtheti össze a felhasználótól, amikor idővel megpróbálják használni az alkalmazás bizonyos funkcióit.

Rendszergazda szervezet nevében végzett hozzájáruláshoz továbbra is szükség van az alkalmazáshoz regisztrált statikus engedélyekre, ezért ezeket az engedélyeket az alkalmazásregisztrációs portálon kell beállítania, ha egy rendszergazdának a teljes szervezet nevében kell hozzájárulást adnia. Ez csökkenti a szervezeti rendszergazda által az alkalmazás beállításához szükséges ciklusokat.

Hatókörök, nem erőforrások

Az 1.0-s verziójú végpontot használó alkalmazások esetében az alkalmazások erőforrásként vagy jogkivonatok címzettjeként viselkedhetnek. Az erőforrások számos, az általuk értelmezett hatókört vagy oAuth2Permissionst definiálhatnak, így az ügyfélalkalmazások jogkivonatokat kérhetnek az adott erőforrástól bizonyos hatókörökhöz. Példaként tekintsük a Microsoft Graph API egy erőforrásra:

  • Erőforrás-azonosító vagy AppID URI: https://graph.microsoft.com/
  • Hatókörök vagy oAuth2Permissions: Directory.Read, Directory.Write, és így tovább.

Ez a Microsoft Identitásplatform végpontra érvényes. Az alkalmazások továbbra is képesek erőforrásként viselkedni, hatóköröket definiálni, és egy URI-vel azonosítani. Az ügyfélalkalmazások továbbra is kérhetnek hozzáférést ezekhez a hatókörökhöz. Azonban megváltozott az a mód, ahogyan az ügyfél kéri ezeket az engedélyeket.

Az 1.0-s verziójú végpont esetében az OAuth 2.0 engedélyezési kérése Azure AD a következőképpen nézhetett ki:

GET https://login.microsoftonline.com/common/oauth2/authorize?
client_id=2d4d11a2-f814-46a7-890a-274a72a7309e
&resource=https://graph.microsoft.com/
...

Itt az erőforrásparaméter jelzi, hogy az ügyfélalkalmazás melyik erőforrást kéri az engedélyezéshez. Azure AD kiszámította az alkalmazás által megkövetelt engedélyeket a Azure Portal statikus konfigurációja alapján, és ennek megfelelően adta ki a jogkivonatokat.

A Microsoft Identitásplatform végpontot használó alkalmazások esetében ugyanaz az OAuth 2.0 engedélyezési kérés a következőképpen néz ki:

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=2d4d11a2-f814-46a7-890a-274a72a7309e
&scope=https://graph.microsoft.com/directory.read%20https://graph.microsoft.com/directory.write
...

Itt a scope paraméter azt jelzi, hogy az alkalmazás melyik erőforrást és engedélyeket kéri az engedélyezéshez. A kívánt erőforrás továbbra is jelen van a kérelemben – a hatókör paraméter minden értékében szerepel. A scope paraméter ily módon történő használata lehetővé teszi, hogy a Microsoft Identitásplatform végpont jobban megfeleljen az OAuth 2.0 specifikációjának, és jobban igazodjon a gyakori iparági eljárásokhoz. Emellett lehetővé teszi az alkalmazások számára, hogy növekményes hozzájárulást végezzenek el – csak akkor kérnek engedélyeket, ha az alkalmazásnak szüksége van rájuk, nem pedig előre.

Jól ismert hatókörök

Offline hozzáférés

A Microsoft Identitásplatform végpontot használó alkalmazásokhoz új, jól ismert engedélyre lehet szükség – a offline_access hatókörre. Minden alkalmazásnak ezt az engedélyt kell kérnie, ha hosszabb ideig egy felhasználó nevében kell hozzáférnie az erőforrásokhoz, még akkor is, ha a felhasználó nem használja aktívan az alkalmazást. A offline_access hatókör a hozzájárulási párbeszédpaneleken az Adatok elérése bármikor lehetőségként jelenik meg a felhasználó számára, amelyet a felhasználónak el kell fogadnia. Az engedély kérése offline_access lehetővé teszi, hogy a webalkalmazás OAuth 2.0 refresh_tokens fogadjon a Microsoft Identitásplatform végpontról. A frissítési jogkivonatok hosszú élettartamúak, és hosszabb ideig használhatók új OAuth 2.0 hozzáférési jogkivonatokra.

Ha az alkalmazás nem kéri le a hatókört offline_access , nem kap frissítési jogkivonatokat. Ez azt jelenti, hogy amikor bevált egy engedélyezési kódot az OAuth 2.0 engedélyezési kódfolyamatában, csak egy hozzáférési jogkivonatot kap vissza a /token végpontról. Ez a hozzáférési jogkivonat rövid ideig (általában egy óráig) érvényes marad, de végül lejár. Ekkor az alkalmazásnak vissza kell irányítania a felhasználót a /authorize végpontra egy új engedélyezési kód lekéréséhez. Az átirányítás során előfordulhat, hogy a felhasználónak újra meg kell adnia a hitelesítő adatait, vagy újra meg kell adnia az engedélyeket az alkalmazás típusától függően.

Az OAuth 2.0- és , refresh_tokensés access_tokens-ről az Microsoft Identitásplatform protokoll referenciájában talál további információt.

OpenID, profil és e-mail

Korábban a legalapvetőbb OpenID Connect bejelentkezési folyamat a Microsoft Identitásplatform sok információt szolgáltatna a felhasználóról az eredményül kapott id_token. A id_token jogcímei közé tartozhat többek között a felhasználó neve, az előnyben részesített felhasználónév, az e-mail-cím, az objektumazonosító.

Mostantól korlátozva van az az információ, amelyhez a openid hatókör hozzáférést biztosít az alkalmazás számára. A openid hatókör csak azt engedélyezi, hogy az alkalmazás bejelentkeztethesse a felhasználót, és alkalmazásspecifikus azonosítót kapjon a felhasználóhoz. Ha személyes adatokat szeretne lekérni a felhasználóról az alkalmazásban, az alkalmazásnak további engedélyeket kell kérnie a felhasználótól. Két új hatókör( email és profile) lehetővé teszi, hogy további engedélyeket kérjen.

  • A email hatókör lehetővé teszi, hogy az alkalmazás hozzáférjen a felhasználó elsődleges e-mail-címéhez a email id_token jogcímén keresztül, feltéve, hogy a felhasználó címezhető e-mail-címmel rendelkezik.
  • A profile hatókör hozzáférést biztosít az alkalmazásnak a felhasználóval kapcsolatos összes egyéb alapvető információhoz, például a felhasználó nevéhez, az előnyben részesített felhasználónévhez, az objektumazonosítóhoz stb. a id_token.

Ezek a hatókörök lehetővé teszik az alkalmazás minimális közzétételi módon történő kódolását, így csak azokat az információkat kérheti a felhasználótól, amelyekre az alkalmazásnak szüksége van a feladatához. További információ ezekről a hatókörökről: Microsoft Identitásplatform hatókör referenciája.

Jogkivonat jogcímek

A Microsoft Identitásplatform végpont alapértelmezés szerint kisebb jogcímkészletet ad ki a jogkivonatokban, hogy a hasznos adatok kis méretűek maradjanak. Ha olyan alkalmazásokkal és szolgáltatásokkal rendelkezik, amelyek egy 1.0-s verziós jogkivonatban egy adott jogcímtől függenek, amely már nem érhető el alapértelmezés szerint egy Microsoft Identitásplatform-jogkivonatban, fontolja meg az opcionális jogcímek funkció használatát a jogcím belefoglalásához.

Fontos

Az 1.0-s és a 2.0-s verziójú jogkivonatokat a v1.0 és a v2.0 végpontok is kibocsáthatják! id_tokens mindig megegyeznek a kért végponttal, és a hozzáférési jogkivonatok mindig megegyeznek az ügyfél által meghívandó webes API által várt formátummal. Ha tehát az alkalmazás a 2.0-s verziójú végpontot használja egy jogkivonat lekéréséhez a Microsoft Graph meghívásához, amely 1.0-s formátumú hozzáférési jogkivonatokat vár, az alkalmazás egy 1.0-s verziójú jogkivonatot fog kapni.

Korlátozások

A Microsoft Identitásplatform használatakor figyelembe kell venni néhány korlátozást.

A Microsoft Identitásplatform integrálható alkalmazások létrehozásakor el kell döntenie, hogy a Microsoft Identitásplatform végpont és a hitelesítési protokollok megfelelnek-e az igényeinek. Az 1.0-s verziójú végpont és platform továbbra is teljes mértékben támogatott, és bizonyos tekintetben több funkcióval rendelkezik, mint Microsoft Identitásplatform. A Microsoft Identitásplatform azonban jelentős előnyökkel jár a fejlesztők számára.

Íme egy egyszerűsített javaslat a fejlesztők számára:

  • Ha személyes Microsoft-fiókokat szeretne vagy kell támogatnia az alkalmazásban, vagy új alkalmazást ír, használja a Microsoft Identitásplatform. Mielőtt azonban mégis, győződjön meg arról, hogy tisztában van a cikkben tárgyalt korlátozásokkal.
  • Ha SAML-re támaszkodó alkalmazást migrál vagy frissít, nem használhatja a Microsoft Identitásplatform. Ehelyett tekintse meg a Azure AD 1.0-s verzióra vonatkozó útmutatót.

A Microsoft Identitásplatform végpont fejlődni fog az itt felsorolt korlátozások kiküszöbölése érdekében, így csak a Microsoft Identitásplatform végpontot kell használnia. Addig is ebből a cikkből megtudhatja, hogy a Microsoft Identitásplatform végpont megfelelő-e Önnek. Továbbra is frissíteni fogjuk ezt a cikket, hogy tükrözze a Microsoft Identitásplatform végpont aktuális állapotát. Térjen vissza, és értékelje újra a követelményeket Microsoft Identitásplatform képességek alapján.

Az alkalmazásregisztrációk korlátozásai

Az Microsoft Identitásplatform végponttal integrálni kívánt alkalmazásokhoz létrehozhat egy alkalmazásregisztrációt az új Alkalmazásregisztrációk felületen a Azure Portal. A meglévő Microsoft-fiókalkalmazások nem kompatibilisek a portállal, de minden Microsoft Entra alkalmazás, függetlenül attól, hogy hol vagy mikor lettek regisztrálva.

Alkalmazásregisztrációk, amely támogatja a munkahelyi és iskolai fiókokat és a személyes fiókokat, a következő kikötésekkel rendelkezik:

  • Alkalmazásazonosítónként csak két titkos alkalmazáskulcs engedélyezett.
  • A bérlőben nem regisztrált alkalmazásokat csak az azt regisztráló fiók kezelheti. Nem osztható meg más fejlesztőkkel. Ez a helyzet a legtöbb olyan alkalmazás esetében, amelyet személyes Microsoft-fiókkal regisztráltak az alkalmazásregisztrációs portálon. Ha több fejlesztővel szeretné megosztani az alkalmazásregisztrációt, regisztrálja az alkalmazást egy bérlőben a Azure Portal új Alkalmazásregisztrációk szakaszával.
  • Az átirányítási URL-cím formátumára számos korlátozás vonatkozik. Az átirányítási URL-címmel kapcsolatos további információkért lásd a következő szakaszt.

Átirányítási URL-címek korlátozásai

A Microsoft Identitásplatform regisztrált alkalmazások átirányítási URL-címére vonatkozó korlátozásokkal kapcsolatos legfrissebb információkért lásd: Átirányítási URI-/válasz URL-címek korlátozásai és korlátozásai a Microsoft Identitásplatform dokumentációjában.

Ha meg szeretné tudni, hogyan regisztrálhat egy alkalmazást a Microsoft Identitásplatform való használatra, olvassa el az Alkalmazás regisztrálása az új Alkalmazásregisztrációk felületen című cikket.

Kódtárakra és SDK-kra vonatkozó korlátozások

Jelenleg a Microsoft Identitásplatform végpont erőforrástár-támogatása korlátozott. Ha éles alkalmazásban szeretné használni a Microsoft Identitásplatform végpontot, az alábbi lehetőségek állnak rendelkezésére:

  • Ha webalkalmazást készít, biztonságosan használhatja az általánosan elérhető kiszolgálóoldali közbenső szoftvereket a bejelentkezéshez és a jogkivonat érvényesítéséhez. Ezek közé tartozik az OWIN OpenID Connect köztes szoftver a ASP.NET és a Node.js Passport beépülő modul. A Microsoft köztes szoftvereket használó kódmintákért tekintse meg a Microsoft Identitásplatform első lépéseket ismertető szakaszt.
  • Ha asztali vagy mobilalkalmazást készít, használhatja a Microsoft Hitelesítési kódtárak (MSAL) egyikét. Ezek a kódtárak általánosan vagy éles környezetben támogatott előzetes verzióban érhetők el, így biztonságosan használhatók éles alkalmazásokban. Az előzetes verzió feltételeiről és az elérhető kódtárakról a hitelesítési kódtárak referenciájában olvashat bővebben.
  • A Microsoft-kódtárak által nem lefedett platformok esetében integrálható a Microsoft Identitásplatform végponttal, ha közvetlenül küld és fogad protokollüzeneteket az alkalmazáskódban. Az OpenID Connect- és OAuth-protokollok kifejezetten dokumentálva vannak , hogy segítsenek az ilyen integrációban.
  • Végül használhat nyílt forráskódú OpenID Connect- és OAuth-kódtárakat a Microsoft Identitásplatform végponttal való integrációhoz. A Microsoft Identitásplatform végpontnak számos, módosítás nélküli nyílt forráskódú protokolltárral kompatibilisnek kell lennie. Az ilyen típusú kódtárak elérhetősége nyelvtől és platformtól függően változik. Az OpenID Connect és az OAuth 2.0 webhelyeken megtalálható a népszerű implementációk listája. További információ: Microsoft Identitásplatform és hitelesítési kódtárak, valamint a Microsoft Identitásplatform végponttal tesztelt nyílt forráskódú ügyfélkódtárak és minták listája.
  • Referenciaként a .well-known Microsoft Identitásplatform közös végpont végpontja a https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. Cserélje le common a elemet a bérlőazonosítóra a bérlőre vonatkozó adatok lekéréséhez.

Protokollmódosítások

A Microsoft Identitásplatform végpont nem támogatja az SAML-t vagy a WS-Federationt, csak az OpenID Connectet és az OAuth 2.0-t támogatja. Az OAuth 2.0 protokollok jelentős változásai az 1.0-s verziójú végponton:

  • A email rendszer akkor adja vissza a jogcímet, ha egy opcionális jogcím van konfigurálva , vagy a scope=email meg lett adva a kérelemben.
  • A scope paraméter mostantól támogatott a resource paraméter helyett.
  • Számos válasz módosult, hogy jobban megfeleljenek az OAuth 2.0 specifikációjának, például helyesen, sztring helyett intként adja vissza expires_in őket.

A Microsoft Identitásplatform végpontban támogatott protokollfunkciók hatókörének jobb megismeréséhez tekintse meg az OpenID Connect és az OAuth 2.0 protokollreferenciáját.

SAML-használat

Ha Active Directory Authentication Libraryt (ADAL) használt Windows-alkalmazásokban, előfordulhat, hogy kihasználta az integrált Windows-hitelesítés előnyeit, amely a Security Assertion Markup Language (SAML) helyességi engedélyt használja. Ezzel a jogosultsággal az összevont Microsoft Entra bérlők felhasználói anélkül végezhetnek csendes hitelesítést a helyi Active Directory-példányukkal, hogy hitelesítő adatokat adnak meg. Bár az SAML továbbra is támogatott protokoll a vállalati felhasználók számára, a 2.0-s verziójú végpont csak OAuth 2.0-alkalmazásokhoz használható.

Következő lépések

További információt a Microsoft Identitásplatform dokumentációjában talál.