Mi az OAuth2.0?

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.

Authorization Code Flow:

• OAuth2.0 (szolgáltatási fiók): 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és szükséges, 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

:::(Figyelmeztetés) (Figyelmeztetés) A felhasználói hitelesítési folyamat befejezéséhez a böngészőnek engedélyeznie kell a felugró ablakokat. Ha a csatlakozó több környezettel van konfigurálva, akkor minden egyes környezet külön felugró ablakot nyit meg a hitelesítés során.

Hogyan ellenőrizheti, hogy a felugró ablakok engedélyezve vannak-e a Chrome-ban:

1. Nyissa meg a Chrome-ot, és kattintson az ablak jobb felső sarkában található hárompontos menüre.
2. A legördülő menüből válassza a Beállítások menüpontot.
3. Görgessen lefelé, és kattintson az Adatvédelem és biztonság menüpontra.
4. Az "Adatvédelem és biztonság" szakasz alatt kattintson a Site Settings (Oldalbeállítások) pontra.
5. Görgessen lefelé, és kattintson a Pop-upok és átirányítások menüpontra.
6. Győződjön meg róla, hogy a kapcsoló a felugró ablakok engedélyezésére van állítva, vagy manuálisan adja hozzá a webhelyet a felugró ablakok megjelenítésére engedélyezett webhelyek listájához.

Ha a felugró ablakok blokkolva vannak, a Chrome egy kis ikont jelenít meg a címsorban, ha egy felugró ablakot blokkol. Erre az ikonra kattintva gyorsan engedélyezheti a Tulip felugró ablakokat.
:::

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

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:

Ü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.

Az OAuth konfigurálása

Engedélyezési kód URL

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.

Alapértelmezett lejárati idő (másodperc)

Ez a mező adja meg azt az alapértelmezett időt (másodpercben), amely után a tokenek frissülnek, ha nincs kifejezetten megadott vagy az expires_in mezőn kívüli más mechanizmuson keresztül meghatározott lejárati idő.

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

Az Audience (célközönség) a felhasználó által elérni kívánt konkrét eszközöket határozza meg, míg a Scope (hatókör) az ezeken az eszközökön kívánt műveleteket. Mindkettőt a 2. lépésben az engedélyezési kódkérés során kell megadni.

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ást állítja be, míg engedélyezve a bejelentkezést, így az OAuth szolgáltató dönthet a megjelenítendő bejelentkezési képernyőről.

Mélyebbre ásni

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

• OAuth2.0 konfiguráció és technikai részletek
• Hogyan futtassunk egy csatlakozófunkciót több környezetben?