OAuth 2.0

Áttekintés

Üdvözöljük az OAuth 2.0 felfedezésében, amely egy hatékony, de gyakran félreértett hitelesítési protokoll a Tulip-világban. Ebben a cikkben feltárjuk az alapokat, végigvezetjük Önt a Tulip által támogatott hitelesítési folyamatokon, elmagyarázzuk az első csatlakozó konfigurálását, és gyors tippeket osztunk meg a zökkenőmentes induláshoz.

A Tulip frissítési tokenek kezelésével, a hatókör- és célközönség-kezeléssel, valamint az egyéni csatlakozók konfigurációjával kapcsolatos információkat a „Műszaki részletek” szakaszban találja.

Hitelesítési típusok

A Tulip három OAuth 2.0 hitelesítési típust támogat: OAuth 2.0 (szolgáltatási fiók), OAuth 2.0 (felhasználói hitelesítő adatok) és OAuth 2.0 (ügyfél hitelesítő adatok). A legfontosabb különbség abban rejlik, hogy a hitelesítő adatok hogyan kerülnek megosztásra a felhasználók között, valamint az OAuth specifikáció szerint végrehajtott folyamatban. Az egyedi OAuth-folyamatok teljes listája és leírása itt található: https://frontegg.com/blog/oauth-flows.

Engedélyezési kód folyamat:

• OAuth 2.0 (szolgáltatási fiók): A Tulip Player összes felhasználója számára a csatlakozó tesztelése során megadott hitelesítő adatokat használja. Ideális a szervezeten belüli megosztott hitelesítő adatokhoz. A hitelesítő adatok lejárta esetén az adminisztrátornak újra kell hitelesítenie a felhasználót.
• OAuth 2.0 (felhasználói hitelesítő adatok): A hitelesítést a Tulip Playerbe bejelentkezett felhasználó alapján végzi. Ha egy felhasználó még nem hitelesítette magát, vagy a hitelesítés lejárt, a felhasználó a Tulip Playerben végzi el az OAuth-folyamatot.

Ügyfél hitelesítő adatok folyamata:

• OAuth 2.0 (ügyfél hitelesítő adatai): Ezt a jogosultsági típust a Tulip arra használja, hogy hozzáférési tokent szerezzen azáltal, hogy az ügyfél hitelesítő adataival (ügyfél-azonosító és ügyfél-titok) hitelesíti magát az engedélyezési szerveren, általában nem egy felhasználó, hanem saját nevében történő erőforrás-hozzáférés céljából.

Mielőtt a részletekbe bocsátkoznánk, javasoljuk, hogy ismerkedjen meg a környezetekkel, és szerezzen áttekintést a csatlakozó-gazdagépekről és azok funkcióiról.

Az OAuth 2.0 olyan mechanizmusként szolgál, amelynek segítségével a Tulip (az ügyfél) igazolja identitását az Ön üzleti rendszereiben.

Engedélyezési kód folyamat

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

Ellenőrizze, hogy a Chrome-ban engedélyezve vannak-e a felugró ablakok:

1. Nyissa meg a Chrome-ot, és kattintson az ablak jobb felső sarkában található három pontból álló menüre.
2. Válassza a Beállítások menüpontot a legördülő menüből.
3. Görgessen lefelé, és kattintson az Adatvédelem és biztonság elemre.
4. Az „Adatvédelem és biztonság” szakasz alatt kattintson a „Webhelybeállítások” elemre.
5. Görgessen lefelé, és kattintson a „Felugró ablakok és átirányítások” elemre.
6. Győződjön meg arról, 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, valahányszor egy felugró ablakot blokkol. Erre az ikonra kattintva gyorsan engedélyezheti a Tulip felugró ablakait.
:::

A hozzáférés egy kézfogáson keresztül történik, és a Tulip elsősorban az engedélyezési kód folyamatot támogatja, amely a leggyakoribb OAuth-folyamat. Íme egy rövid áttekintés arról, hogyan zajlik ez a folyamat:

1. A felhasználó a „Teszt” gombra kattintva indítja el a folyamatot, mielőtt elmentené a csatlakozót.
2. A Tulip kommunikál az OAuth-szolgáltatója engedélyezési szerverével, és megosztja vele bizonyos paramétereket, például az ügyfél azonosítóját, a hatóköröket (amelyekhez hozzáférést próbál szerezni) és egyéb releváns részleteket.
3. Az engedélyezési szerver felkéri a felhasználót, hogy adja meg a hozzáférést, amint az alábbi példában látható:

1. A felhasználó beleegyezése után az engedélyezési szerver generál egy engedélyezési kódot, és bezárja a hitelesítési ablakot.
2. Az engedélyezési kód birtokában a Tulip biztonságosan token-t kér a token végponttól, megadva az engedélyezési kódot, az ügyfél-azonosítót, az ügyfél-titkot és további tulajdonságokat.
3. Az engedélyezési kód érvényesítése után a szerver 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 mostantól a felhasználók nevében hajthat végre kéréseket a megadott token segítségével az engedélyezéshez.

A végrehajtás menetét az alábbi ábrák szemléltetik:

Ügyfélhitelesítő adatok áramlása

Az ügyfél hitelesítő adatainak folyamatát elsősorban két üzleti rendszer közötti interakcióra használják. Ezt a folyamatot egyszer kell konfigurálni, majd azt minden felhasználó megosztja.

1. A felhasználó a csatlakozó mentése előtt a „Teszt” gombra kattintva indítja el a folyamatot.
2. A Tulip kommunikál az OAuth-szolgáltatója hitelesítési szerverével, és megosztja vele bizonyos paramétereket, például az ügyfél azonosítóját, a hatóköröket (amelyekhez hozzáférést próbál szerezni) és egyéb releváns részleteket.
3. Az engedélyezési szerver visszaad egy hozzáférési tokent, feltéve, hogy az ügyfél-azonosító és az ügyfél-titok helyesek. Opcionálisan frissítési token is visszaadható. Ez a token a felhasználó által engedélyezett kérésekhez szolgál.
4. A Tulip most már a felhasználók nevében végrehajthatja a kéréseket a megadott engedélyezési token segítségével.

Az OAuth beállítása

Engedélyezési kód URL-je

Ez az az URL, amelyhez a Tulip a hitelesítési kód folyamat 2. lépésében kapcsolódik. Az OAuth-szolgáltató API-dokumentációjában található, és általában /auth vagy /authorize végződéssel zárul.

Megjegyzés: Ez a mező nem jelenik meg az ügyfélhitelesítő adatok esetében.

Hozzáférési token URL-je

Az engedélyező szerver válaszát követően kérés érkezik a hozzáférési token URL-jére a hitelesítéshez szükséges token megszerzése érdekében. Általában /token végződéssel zárul.

Ügyfél-azonosító és ügyfél-titok

Az OAuth-szolgáltató felhasználói felületén generált kliens-azonosítót az engedélyezési kódra vonatkozó kezdeti kéréssel együtt továbbítják. A kliens-azonosító és a kliens-titok minden token-kéréshez csatolva van.

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

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

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

A célközönség meghatározza azokat a konkrét erőforrásokat, amelyekhez a felhasználó hozzáférést kér, míg a hatókör meghatározza az ezeken az erőforrásokon végrehajtani kívánt műveleteket. Mindkettőt a 2. lépésben, az engedélyezési kód kérés során továbbítják.

További beállítások

• A tokenkérés adatainak JSON formátumban történő elküldése: Megváltoztatja a token URL-re küldött kérés kódolási típusát. Szükség esetén engedélyezze bizonyos integrációkhoz.
• Hitelesítési fejléc küldése a frissítési kérelemhez: Ha engedélyezve van, egy további fejlécet ad a frissítési kérelmekhez.
• A felhasználói hozzájárulás kérésének kihagyása: A hitelesítési kódkérés prompt attribútumát szabályozza. Letiltva a beállítás „hozzájárulás” értékre áll, míg engedélyezve „bejelentkezés” értékre áll, így az OAuth-szolgáltató dönti el, melyik bejelentkezési képernyőt jeleníti meg.

Műszaki részletek

Az alábbiakban részletesen bemutatjuk, mit támogat a Tulip, és hogyan integrálódik az OAuth a csatlakozók hitelesítéséhez.

A Tulip engedélyezési kód-folyamata

A Tulip elindítja a hitelesítési folyamatot, amikor egy csatlakozót tesztel, vagy egy alkalmazáson belül csatlakozófüggvényt futtat.

1. Átirányítás az engedélyezési szerverre

A Tulip alkalmazás átirányítja a felhasználót az engedélyezési szerverre (AS) bizonyos paraméterekkel együtt, beleértve a response_type-ot (amelyet az engedélyezési kód folyamat esetében „code”-ra állítanak be), a client_id-t (amelyet a csatlakozó felhasználói felületén rendelnek hozzá), a redirect_uri-t (amelyet a Tulip előre meghatároz), a scope-ot és az audience-t (amelyeket a felhasználói felületen állítanak be), valamint a state-et (egy véletlenszerű karakterlánc, amely védelmet nyújt a Cross-Site Request Forgery támadások ellen).

Példa: GET /authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=SCOPE&audience=AUDIENCE&state=STATE

2. A felhasználó megadja a hozzájárulását

Az engedélyező szerver hitelesíti a felhasználót, majd megjeleníti számára a hozzájárulási képernyőt. A felhasználó áttekintheti a kért engedélyeket, és eldöntheti, hogy megadja-e vagy megtagadja-e a hozzáférést a harmadik fél alkalmazásához.

:::(Figyelem) (Megjegyzés)
Egy adott connector konfigurációján belül a „Skip user consent prompt” vezérlővel szabályozhatja a hitelesítési kérelem prompt attribútumát. Ha ez a vezérlő ki van kapcsolva, a consent érték kerül felhasználásra; ha be van kapcsolva, a login érték kerül felhasználásra.

Ha a prompt attribútum további értékei szükségesek, vegye fel a kapcsolatot a support@tulip.co címmel, és további lehetőségeket fogunk engedélyezni ehhez a tulajdonsághoz.
:::

3. Engedélyezési kód

Ha a felhasználó megadja a hozzájárulását, az engedélyezési szerver létrehoz egy engedélyezési kódot, és a kóddal együtt visszatereli a felhasználót a Tulipba. A válaszban szerepel a „state” paraméter is, amely lehetővé teszi az ügyfél számára a válasz integritásának ellenőrzését. Ennek a „state” paraméternek meg kell egyeznie az 1. lépésben átadott „state” paraméterrel.

Példa az ügyfél átirányítási URI-jára történő átirányításra:

REDIRECT_URI?code=AUTHORIZATION_CODE&state=STATE

4. Token-kérés

Az ügyfélnek most már rendelkezésére áll az engedélyezési kód, amelyet felhasználva biztonságos, szerver-szerver közötti kérést küld az engedélyezési szerver token-végpontjára. Az ügyfél a kérésbe belefoglalja a grant_type-ot (amelynek értéke „authorization_code”), a client_id-t, a client_secret-et (egy olyan titkos kulcsot, amelyet csak az ügyfél és az engedélyezési szerver ismer), a redirect_uri-t és az engedélyezési kódot.

Példa token-kérésre:

grant\_type=authorization\_code&code=AUTHORIZATION\_CODE&redirect\_uri=REDIRECT\_URI&client\_id=CLIENT\_ID&client\_secret=CLIENT\_SECRET```

### 5. Hozzáférési token válasz:

Ha az engedélyezési kód érvényes, az engedélyezési szerver hozzáférési tokennel, valamint opcionálisan frissítési tokennel válaszol. A hozzáférési tokent az ügyfél használja a hitelesítéshez, amikor a felhasználó nevében kéréseket küld a védett API-hoz.

**Példa a token-válaszra:**

`{ "access_token": "ACCESS_TOKEN", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "REFRESH_TOKEN", "scope": "SCOPE"}`

:::(Warning) (Services Not Using `expires_in`)
  
If the token's expiration time is not provided via the `expires_in` key, the "Default Expiration Time (seconds)" field in the authentication configuration will be used to automate token renewal.  
:::

### 6. Hozzáférés az erőforrás-kiszolgálóhoz

A Tulip most már felhasználhatja a megszerzett hozzáférési tokent arra, hogy a felhasználó nevében engedélyezett kéréseket küldjön az erőforrás-kiszolgálónak (API). A hozzáférési token általában az HTTP-kérés Authorization fejlécében szerepel.

**Példa API-kérésre:**`GET /api/resource Authorization: Bearer ACCESS_TOKEN`

## A tokenek lejáratának kezelése frissítési tokenekkel

Az engedélyezési szerverek általában lejárati dátumokat állítanak be a tokenekhez a hozzáférés szabályozása érdekében, amelyek az összekapcsolt rendszertől függően változó időtartamúak. A rövid élettartamú tokenek azonban kihívást jelentenek, mivel a folyamatos felhasználói hitelesítés megzavarja a felhasználói élményt a Tulip-alkalmazásokban.

Ennek a problémának a megoldására az OAuth támogatja a frissítési tokeneket. Bár ezek használata opcionális, erősen ajánlottak, mivel egyszerűsítik a felhasználói élményt azáltal, hogy lehetővé teszik a Tulip számára a tokenek zökkenőmentes frissítését anélkül, hogy az operátoroknak manuálisan be kellene avatkozniuk.

### Hogyan kezeli a Tulip a tokenek frissítését?

Amikor a Tulip észleli, hogy egy hozzáférési token lejárt, automatikusan megpróbálja a hozzá tartozó frissítő tokent felhasználni egy új token megszerzéséhez. Az elsődleges cél a felhasználók újbóli hitelesítésének minimalizálása. Az alábbi lépések vázolják a Tulip által végrehajtott logikát:

![Token Refresh Flow](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/image%28399%29.png)

**1. Lejárás észlelése:** - A Tulip a hitelesítési folyamat [5. lépésében](/r230/docs/oauth20-configuration-and-technical-details#5-access-token-response) kapott `expires_in` attribútum alapján azonosítja a lejárt tokent.

:::(Warning) (Services Not Using `expires_in`)
  
If the token's expiration time is not provided via the `expires_in` key, the "Default Expiration Time (seconds)" field in the authentication configuration will be used to automate token renewal.  
:::

**2. Tokenfolyamat-kezdeményezés:** - A Tulip a `refresh_token` engedélytípust használva indítja el a tokenfolyamatot, felváltva a kezdeti hitelesítési folyamatban használt engedélytípust.

**3. Token-érvényesítés:** - Ha új token szerezhető be, a Tulip azt tárolja, majd folytatja a felhasználó által kért „ connector function ” végrehajtását. - Siker esetén az adatok átadásra kerülnek a Tulip alkalmazás futtatókörnyezetének. - Ha az új token OAuth-hibával bukik meg, a Tulip legfeljebb 5-ször megismétli a folyamatot, minden alkalommal visszatérve az 1. lépéshez. - Ha az új token bármilyen más hibával bukik meg, a lejátszó futtatókörnyezetében hibaüzenet jelenik meg.

**4. Token hiánya esetén:** - Ha nem adnak meg új tokent, a Tulip a lejátszóban felszólítja a felhasználót a hitelesítés elvégzésére, ezzel elindítva a teljes hitelesítési folyamatot. - A folyamat befejezése után a connector function parancs végrehajtásra kerül, és az adatok visszajutnak.

A frissítési tokenek bevezetésével a Tulip intelligensen kezeli a tokenek lejáratát és megújítását, így biztosítva a zökkenőmentesebb felhasználói élményt és minimalizálva a munkafolyamat megszakításait.

---

Megtalálta, amit keresett?

Látogasson el [a community.tulip.co](https://community.tulip.co/?utm_source=intercom&utm_medium=article-link&utm_campaign=all) oldalra is, ahol felteheti kérdését, vagy megnézheti, hogy mások is szembesültek-e hasonló problémával!