Mi az OAuth2.0?
  • 28 Aug 2024
  • 4 Elolvasandó percek
  • Közreműködők

Mi az OAuth2.0?


Cikk összefoglaló

Az OAuth2.0 felfedezése

Üdvözöljük az OAuth2.0, egy nagy teljesítményű, de gyakran félreértett hitelesítési protokoll felfedezésében a Tulip-verzumban. Ebben a cikkben feltárjuk az alapokat, végigvezetjük Önt a Tulip támogatott hitelesítési folyamatain, demisztifikáljuk a kezdeti csatlakozó konfigurálását, és gyors tippeket osztunk meg a zökkenőmentes induláshoz.

Az OAuth2.0 bonyolult lehet, és a tömörség kedvéért néhány részletes technikai szempontot kihagytunk ebből a cikkből. Ha szeretne mélyebben elmerülni a Tulip frissítési tokenek kezelésében, a hatókör és a közönség kezelésében, valamint az egyéni csatlakozó-konfigurációkban, akkor javasoljuk, hogy tekintse meg ezt a részletes OAuth2.0 technikai útmutatót.

Hitelesítési típusok

A Tulip három OAuth2.0 hitelesítési típust támogat: OAuth2.0 (szolgáltatási fiók), OAuth2.0 (felhasználói hitelesítő adatok) és OAuth2.0 (ügyfél hitelesítő adatok). A legfontosabb különbség abban rejlik, hogy a hitelesítő adatokat hogyan osztják meg a felhasználók között, és milyen folyamatot hajtanak végre az OAuth specifikációval szemben. Az egyedi OAuth-áramlások teljes listája és leírása itt érhető el: https://frontegg.com/blog/oauth-flows.

:::(Info) (Megjegyzés) A Tulip régebbi verzióiban az OAuth2.0 (Service Account) az OAuth2 (Admin), az OAuth2.0 (User Credentials) pedig az OAuth2 (Operator) nevet viselte. :::

Authorization Code Flow:

  • OAuth2.0 (Service Account): A csatlakozó tesztelése során megadott hitelesítő adatokat használja a Tulip Player összes felhasználója számára. Ideális a szervezeten belül megosztott hitelesítő adatokhoz. Admin újbóli hitelesítésre van szükség, ha a hitelesítő adatok lejárnak.
  • OAuth2.0 (felhasználói hitelesítő adatok): A hitelesítést a Tulip Playerbe bejelentkezett felhasználó alapján szegmentálja. Ha egy felhasználó nem hitelesített, vagy a hitelesítés lejár, a felhasználó a Tulip Playerben az OAuth-áramláson megy keresztül.

Ügyfél hitelesítő adatok áramlása:

  • OAuth2.0 (Ügyfél hitelesítő adatok): Ezt az engedélyezési típust a Tulip az ügyfél hitelesítő adatainak (ügyfél-azonosító és ügyféltitok) felhasználásával az engedélyező kiszolgálón történő hitelesítéssel hozzáférési token megszerzésére használja, jellemzően az erőforrásokhoz való hozzáféréshez saját nevében, nem pedig egy felhasználó nevében.

Az alapok bemutatása

Mielőtt belemerülne a konkrétumokba, javasoljuk, hogy ismerkedjen meg a Környezetekkel, és szerezzen áttekintést a csatlakozógazda-szolgáltatókról és azok funkcióiról.

Az OAuth2.0 a Tulip (az ügyfél) azonosítására szolgáló mechanizmusként szolgál az Ön üzleti rendszereivel.

Engedélyezési kódfolyamat

A hozzáférés biztosítása kézfogással történik, és a Tulip elsősorban az Authorization Code Flow-t, a leggyakoribb OAuth-áramlást támogatja. Íme egy tömörített áttekintés arról, hogyan bontakozik ki ez az áramlás:

  1. A felhasználó a csatlakozó mentése előtt a Teszt gombra kattintva kezdeményezi az áramlást.
  2. A Tulip kommunikál az OAuth-szolgáltató engedélyezési kiszolgálójával, és megosztja a konkrét paramétereket, például az ügyfél azonosítóját, a hatóköröket (azt, hogy mihez próbál hozzáférni) és egyéb releváns részleteket.
  3. Az engedélyező kiszolgáló felkéri a felhasználót a hozzáférés engedélyezésére, az alábbi példával szemléltetve:

  1. A felhasználó beleegyezését követően az engedélyező kiszolgáló létrehoz egy engedélyezési kódot, és lezárja a hitelesítési ablakot.
  2. Az engedélyezési kóddal felfegyverkezve a Tulip biztonságosan kér egy tokent a token végpont elérésével, megadva az engedélyezési kódot, az ügyfél azonosítót, az ügyféltitkot és további tulajdonságokat.
  3. Az engedélyezési kód érvényesítését követően a kiszolgáló egy tokennel és opcionálisan egy frissítési tokennel válaszol. Ez a token a felhasználó által engedélyezett kérésekhez szolgál.
  4. A Tulip most már képes a felhasználók nevében kéréseket végrehajtani, a megadott tokennel az engedélyezéshez.

A végrehajtás útjának megértéséhez lásd az alábbi diagramokat:Token Request

OAuth2 Graphic

Ügyfél hitelesítő adatok áramlása

Az ügyfél hitelesítő adatok áramlását elsősorban két üzleti rendszer interakciójára használják. Ezt az áramlást egyszer kell konfigurálni, majd az összes felhasználó megosztja.

  1. A felhasználó az áramlást a Teszt gombra kattintva indítja el, mielőtt elmenti a csatlakozót.
  2. A Tulip kommunikál az OAuth-szolgáltató engedélyezési kiszolgálójával, és megosztja az olyan speciális paramétereket, mint az ügyfél azonossága, a hatókörök (mihez próbál hozzáférni) és egyéb releváns részletek.
  3. Az engedélyező kiszolgáló egy hozzáférési tokent küld vissza, feltéve, hogy az ügyfél azonosító és az ügyfél titok pontos. Opcionálisan egy frissítési token is visszaküldhető. Ez a token a felhasználó által engedélyezett kérésekhez szolgál.
  4. A Tulip most már képes a felhasználók nevében kéréseket végrehajtani, a megadott tokennel az engedélyezéshez.

Client Credentials Flow

Az OAuth konfigurálása

:::(Warning) (On-Prem szolgáltatások) Az Authorize és a Token végpontoknak elérhetőnek kell lenniük a felhőben ahhoz, hogy a Tulip végre tudja hajtani a csatlakozók hitelesítését :::

OAuth Configuration

Engedélyezési kód URL címe

Ez az az URL, amellyel a Tulip a hitelesítési kódfolyamat 2. lépésében kapcsolatba lép. Az OAuth szolgáltató API dokumentációjában található, jellemzően /auth vagy /authorize végződéssel.

Megjegyzés: Ez a mező nincs jelen az ügyfélhitelesítési adatok esetében.

Hozzáférési token URL

Az engedélyező kiszolgáló válasza után a hitelesítéshez szükséges token megszerzése érdekében kérés érkezik az Access Token URL címre. Általában /token végződésű.

Megjegyzés: Ez a mező nincs jelen az ügyfélhitelesítési adatok esetében.

Ügyfél azonosító és ügyféltitok

Az OAuth-szolgáltató felhasználói felületéről generált Ügyfél-azonosítót a kezdeti engedélyezési kódkérelemmel együtt adják át. Az ügyfél-azonosító és az ügyféltitok minden token-kérelemhez tartozik.

Célközönség és hatókör

Az Audience meghatározza a felhasználó által elérni kívánt konkrét eszközöket, míg a Scope az ezeken az eszközökön kívánt műveleteket. Mindkettő a 2. lépésben szereplő engedélyezési kódkérés során kerül átadásra.

További lehetőségek

  • A token-kérelem adatainak JSON-ként történő elküldése: A token URL-címére küldött kérés kódolási típusának megváltoztatása. Engedélyezze, ha szükséges bizonyos integrációkhoz.
  • Hitelesítési fejléc küldése a frissítési kérelemhez: Ha engedélyezve van, egy extra fejlécet ad a frissítési kérésekhez.
  • Skip User Consent Prompt (Felhasználói beleegyezés kérés kihagyása): Vezérli a hitelesítési kódkérés prompt attribútumát. Kikapcsolva a hozzájárulás, míg engedélyezve a bejelentkezés értékét állítja be, így az OAuth szolgáltató dönthet a megjelenítendő bejelentkezési képernyőről.

:::(Warning) (Megjegyzés) Egyes integrációk esetében zárja ki vagy állítsa a prompt attribútumot a nincsre. További funkciókért forduljon a support@tulip.co címre. :::

Mélyebbre ásni

További betekintésre vágyik? Fedezze fel ezeket a cikkeket:


Hasznos volt ez a cikk?