OAuth 2.0 és OpenID Connect (OIDC) a Microsoft Identitásplatform

A Microsoft Identitásplatform használatához nem kell megtanulnia az OAuth vagy az OpenID Connect (OIDC) protokollszinten történő használatát. Ezeket és más protokollfogalmakat azonban az identitásplatform használatával a hitelesítési funkciók alkalmazáshoz való hozzáadásához fogja használni.

A Azure Portal, a dokumentáció és a hitelesítési kódtárak használata során néhány ilyen alapismeret ismeretével megkönnyítheti az integrációs és hibakeresési feladatokat.

Szerepkörök az OAuth 2.0-ban

Általában négy fél vesz részt az OAuth 2.0 és az OpenID Connect hitelesítési és engedélyezési cseréjében. Az ilyen cseréket gyakran hitelesítési folyamatoknak vagy hitelesítési folyamatoknak nevezik.

Az OAuth 2.0 szerepköröket bemutató ábra

  • Engedélyezési kiszolgáló – Maga a Microsoft Identitásplatform az engedélyezési kiszolgáló. Identitásszolgáltatónak vagy identitásszolgáltatónak is nevezik, biztonságosan kezeli a végfelhasználók adatait, hozzáférését és a hitelesítési folyamatban részt vevő felek közötti megbízhatósági kapcsolatokat. Az engedélyezési kiszolgáló kiadja az alkalmazások és API-k által az erőforrásokhoz való hozzáférés (engedélyezés) megadásához, megtagadásához vagy visszavonásához használt biztonsági jogkivonatokat, miután a felhasználó bejelentkezett (hitelesített).

  • Ügyfél – Az OAuth-csereügyfél az az alkalmazás, amely hozzáférést kér egy védett erőforráshoz. Az ügyfél lehet egy kiszolgálón futó webalkalmazás, egy felhasználó webböngészőjében futó egyoldalas webalkalmazás vagy egy másik webes API-t meghívó webes API. Az ügyfél neve gyakran ügyfélalkalmazás, alkalmazás vagy alkalmazás.

  • Erőforrás-tulajdonos – A hitelesítési folyamat erőforrás-tulajdonosa általában az alkalmazásfelhasználó, vagy az OAuth-terminológia végfelhasználója. A végfelhasználó "birtokolja" a védett erőforrást – az adataikat – az alkalmazás a saját nevében fér hozzá. Az erőforrás tulajdonosa engedélyezheti vagy megtagadhatja az alkalmazás (az ügyfél) hozzáférését a saját erőforrásaihoz. Előfordulhat például, hogy az alkalmazás meghívja egy külső rendszer API-ját, hogy lekérje a felhasználó e-mail-címét a rendszer profiljából. A profiladatok olyan erőforrások, amelyek a végfelhasználó tulajdonában van a külső rendszeren, és a végfelhasználó jóváhagyhatja vagy megtagadhatja az alkalmazás adathozzáférési kérelmét.

  • Erőforrás-kiszolgáló – Az erőforrás-kiszolgáló üzemelteti vagy hozzáférést biztosít egy erőforrás-tulajdonos adataihoz. Az erőforrás-kiszolgáló leggyakrabban egy adattárat kezelő webes API. Az erőforrás-kiszolgáló az engedélyezési kiszolgálóra támaszkodik a hitelesítés végrehajtásához, és az engedélyezési kiszolgáló által kiadott tulajdonosi jogkivonatokban található információkat használja az erőforrásokhoz való hozzáférés engedélyezéséhez vagy megtagadásához.

Tokenek

A hitelesítési folyamatban részt vevő felek tulajdonosi jogkivonatokkal biztosítják, ellenőrzik és hitelesítik a rendszerbiztonsági tagokat (felhasználót, gazdagépet vagy szolgáltatást), valamint hozzáférést biztosítanak vagy megtagadnak a védett erőforrásokhoz (engedélyezés). A Microsoft Identitásplatform tulajdonosi jogkivonatai JSON webes jogkivonatként (JWT) vannak formázva.

A Microsoft Identitásplatform háromféle tulajdonosi jogkivonatot használ biztonsági jogkivonatként:

  • Hozzáférési jogkivonatok – A hozzáférési jogkivonatokat az engedélyezési kiszolgáló bocsátja ki az ügyfélalkalmazás számára. Az ügyfél hozzáférési jogkivonatokat ad át az erőforrás-kiszolgálónak. A hozzáférési jogkivonatok tartalmazzák azokat az engedélyeket, amelyeket az ügyfél az engedélyezési kiszolgálótól kapott.

  • Azonosító jogkivonatok – Az azonosító jogkivonatokat az engedélyezési kiszolgáló bocsátja ki az ügyfélalkalmazásnak. Az ügyfelek azonosító jogkivonatokat használnak a felhasználók bejelentkezésekor, és alapszintű információkat kapnak róluk.

  • Frissítési jogkivonatok – Az ügyfél egy frissítési jogkivonatot vagy RT-t használ az új hozzáférési és azonosító jogkivonatok kéréséhez az engedélyezési kiszolgálótól. A kódnak átlátszatlannak kell tekintenie a frissítési jogkivonatokat és a sztringtartalmakat, mert csak az engedélyezési kiszolgáló használhatja őket.

Alkalmazásregisztráció

Az ügyfélalkalmazásnak meg kell bíznia a Microsoft Identitásplatform által neki kiadott biztonsági jogkivonatokban. A megbízhatóság létrehozásának első lépése az alkalmazás azure Active Directoryban (Azure AD) való regisztrálása az identitásplatformon.

Amikor regisztrálja az alkalmazást a Azure AD, a Microsoft Identitásplatform automatikusan hozzárendel bizonyos értékeket, míg mások az alkalmazás típusa alapján konfigurálhatók.

A leggyakrabban hivatkozott alkalmazásregisztrációs beállítások közül kettő a következő:

  • Alkalmazás (ügyfél) azonosítója – Az alkalmazásazonosítónak és az ügyfél-azonosítónak is nevezett értéket a Microsoft Identitásplatform rendeli hozzá az alkalmazáshoz. Az ügyfél-azonosító egyedileg azonosítja az alkalmazást az identitásplatformon, és szerepel a platformmal kapcsolatos biztonsági jogkivonatokban.
  • Átirányítási URI – Az engedélyezési kiszolgáló átirányítási URI használatával átirányítja az erőforrás-tulajdonos felhasználói ügynökét (webböngésző, mobilalkalmazás) egy másik helyre az interakció befejezése után. Ha például a végfelhasználó hitelesíti magát az engedélyezési kiszolgálóval. Nem minden ügyféltípus használ átirányítási URI-kat.

Az alkalmazás regisztrációja a kódban használt hitelesítési és engedélyezési végpontokról is tartalmaz információkat az azonosítók és hozzáférési jogkivonatok lekéréséhez.

Végpontok

A Microsoft Identitásplatform az OAuth 2.0 és az OpenID Connect (OIDC) 1.0 szabványnak megfelelő implementációit használó hitelesítési és engedélyezési szolgáltatásokat kínál. Az olyan szabványoknak megfelelő engedélyezési kiszolgálók, mint a Microsoft Identitásplatform http-végpontok készletét biztosítják, amelyeket a felek használhatnak egy hitelesítési folyamatban a folyamat végrehajtásához.

Az alkalmazás végponti URI-jai akkor jönnek létre, amikor regisztrálja vagy konfigurálja az alkalmazást Azure AD. Az alkalmazás kódjában használt végpontok az alkalmazás típusától és az általa támogatott identitásoktól (fióktípusoktól) függenek.

Két gyakran használt végpont az engedélyezési végpont és a jogkivonat-végpont. Íme néhány példa a és token a authorize végpontra:

# Authorization endpoint - used by client to obtain authorization from the resource owner.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/authorize
# Token endpoint - used by client to exchange an authorization grant or refresh token for an access token.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/token

# NOTE: These are examples. Endpoint URI format may vary based on application type,
#       sign-in audience, and Azure cloud instance (global or national cloud).

#       The {issuer} value in the path of the request can be used to control who can sign into the application. 
#       The allowed values are **common** for both Microsoft accounts and work or school accounts, 
#       **organizations** for work or school accounts only, **consumers** for Microsoft accounts only, 
#       and **tenant identifiers** such as the tenant ID or domain name.

Ha meg szeretné keresni egy regisztrált alkalmazás végpontját, a Azure Portal keresse meg a következőt:

Azure Active Directory>><Alkalmazásregisztrációk YOUR-APPLICATION-végpontok>>

Következő lépések

Ezután megismerheti az egyes alkalmazástípusok által használt OAuth 2.0 hitelesítési folyamatokat, valamint az alkalmazásokban használható kódtárakat a végrehajtásukhoz:

Határozottan javasoljuk, hogy saját kódtárat vagy nyers HTTP-hívásokat hoz létre a hitelesítési folyamatok végrehajtásához. A Microsoft hitelesítési kódtára biztonságosabb és egyszerűbb. Ha azonban az Ön forgatókönyve megakadályozza a kódtárak használatát, vagy csak többet szeretne megtudni az identitásplatform implementálásáról, a következő protokollreferenciával rendelkezünk: