OAuth2.0 konfiguráció és technikai részletek

Frissítve 23 Jan 2025
4 Elolvasandó percek
Közreműködők

Nyomtat
Részvény

Cikk összefoglaló

Hasznosnak találta ezt az összefoglalót?

Köszönjük visszajelzését

Ebben a cikkben mélyen beleássuk magunkat annak technikai részleteibe, hogyan valósítja meg a Tulip az OAuth-ot a csatlakozó-hitelesítéshez. Az OAuth nagy teljesítményű, de ez némi hozzáadott összetettséggel jár. Ennek az útmutatónak az a célja, hogy megválaszoljon minden technikai kérdést azzal kapcsolatban, hogy mit támogat a Tulip, és hogyan van integrálva.

Megjegyzés: Az Ügyfél hitelesítő adatok áramlása némileg eltér az engedélyezési kód áramlásától. Az 1. és 2. lépés nem releváns az Ügyfél hitelesítő adatok áramlásához.

Tulip engedélyezési kód áramlás

On-Prem Services

The Authorize and Token endpoints must be accessible to the cloud for Tulip to execute authentication for connectors

A Tulip kezdeményezi a hitelesítési folyamatot, amikor egy csatlakozót tesztel vagy egy alkalmazáson belül egy csatlakozófunkciót futtat.

1. Átirányítás az engedélyezési kiszolgálóhoz:

A Tulip alkalmazás átirányítja a felhasználót az engedélyezési kiszolgálóhoz (AS), meghatározott paraméterekkel együtt, beleértve a response_type (az engedélyezési kódáramláshoz "code"-ra van beállítva), a client_id (a csatlakozó felhasználói felületén van hozzárendelve), a redirect_uri (a Tulip által előre meghatározott), a scope és a audience (a felhasználói felületen van beállítva), és az állapot (egy véletlenszerű karakterlánc a Cross-Site Request Forgery támadások elleni védelem érdekében).

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ó hozzájárulását adja:

Az engedélyező kiszolgáló hitelesíti a felhasználót, és megjeleníti neki a beleegyezési képernyőt. A felhasználó áttekintheti a kért engedélyeket, és eldöntheti, hogy megadja vagy megtagadja a hozzáférést a harmadik féltől származó alkalmazáshoz.

:::(Figyelmeztetés) (Megjegyzés) Az adott csatlakozó konfigurációján belül a "Skip user consent prompt" (A felhasználói hozzájárulás kérése kihagyása) vezérlőelem lehetővé teszi az engedélyezési kérés kérés attribútumának vezérlését. Ha ez a vezérlő kikapcsolva van, akkor a hozzájárulás értéket fogja használni, ha engedélyezve van, akkor a bejelentkezés értéket fogja használni.

Ha a prompt attribútum további értékeire van szükség, vegye fel a kapcsolatot a support@tulip.co címen, és mi 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ást, az engedélyező kiszolgáló generál egy engedélyezési kódot, és az engedélyezési kóddal együtt visszairányítja a felhasználót a Tuliphoz. Az állapot paraméter is szerepel, így az ügyfél ellenőrizheti a válasz integritását. Ennek az állapotparaméternek meg kell egyeznie az 1. lépésben átadott állapotparaméterrel.

Példa átirányítás az ügyfél átirányítási URI-jára:

code=AUTHORIZATION_CODE&state=STATE

4. Token kérés:

Az ügyfél most már rendelkezik az engedélyezési kóddal, és azt használja fel egy biztonságos, kiszolgálótól kiszolgálóig terjedő kéréshez az engedélyező kiszolgáló token végpontjához. Az ügyfél tartalmazza a grant_type (az "authorization_code"-ra állítva), a client_id, a client_secret (egy titok, amelyet csak az ügyfél és az engedélyező kiszolgáló ismer), a redirect_uri és az engedélyezési kódot.

Példa token-kérelem:

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


### 5. Access Token válasz:


Ha az engedélyezési kód érvényes, az engedélyező kiszolgáló egy hozzáférési tokennel és opcionálisan egy frissítési tokennel válaszol. A hozzáférési tokent az ügyfél a saját hitelesítésére használja, amikor a felhasználó nevében kéréseket intéz a védett API-hoz.


Példa a token válaszára:


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


:::(Warning) (Services Not Using `expires_in`)

:::


### 6. Az erőforrás-kiszolgáló elérése:


A Tulip most már a megszerzett hozzáférési token segítségével a felhasználó nevében engedélyezett kéréseket intézhet az erőforrás-kiszolgálóhoz (API). A hozzáférési token általában a HTTP-kérelem Authorization fejlécében szerepel.


Példa API-kérelem`: GET /api/resourceAuthorization: Bearer ACCESS_TOKEN`


## A token lejáratának kezelése frissítő tokenekkel


Az engedélyezési kiszolgálók általában lejárati dátumokat állítanak be a tokenekhez a hozzáférés szabályozására, a lejárati időablakok a kapcsolódó rendszertől függően eltérőek. A rövid élettartamú tokenek azonban kihívást jelentenek, mivel az állandó felhasználói hitelesítés megzavarja a felhasználói élményt a Tulip alkalmazásokban.


E probléma megoldására az OAuth támogatja a frissítő tokeneket. Bár opcionálisak, erősen ajánlottak, mivel egyszerűsítik a felhasználói élményt, mivel lehetővé teszik a Tulip számára a tokenek zökkenőmentes frissítését anélkül, hogy a kezelőktől kézi beavatkozást igényelne.


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


Amikor a Tulip azt észleli, hogy egy hozzáférési token lejárt, automatikusan megpróbálja a hozzá tartozó frissítési tokent haszná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. A következő 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árat észlelése:**
2. 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`)

:::


1. **Token flow kísérlet:**
2. A Tulip a token-áramlást a `refresh_token` engedélyezési típus használatával kezdeményezi, a kezdeti hitelesítési áramlásban használt engedélyezési típus helyett.
3. **Token érvényesítés:**
4. Ha új tokent kapunk, a Tulip tárolja azt, és folytatja a felhasználó által kért csatlakozó funkció végrehajtását.


	* Ha sikeres, az adatok a Tulip alkalmazás futási idejének rendelkezésére állnak.
	* Ha az új token OAuth-hiba miatt nem sikerül, a Tulip legfeljebb 5 alkalommal próbálja meg újra a folyamatot, és minden alkalommal visszatér az 1. lépéshez.
	* Ha az új token bármilyen más hibával sikertelen, a lejátszó futási idejében hibaüzenet jelenik meg.
5. **Token hiányának kezelése:**
6. Ha nincs új token, a Tulip felszólítja a felhasználót a lejátszóban a hitelesítésre, és elindítja a teljes hitelesítési folyamatot.
7. A folyamat befejezése után a csatlakozó függvény végrehajtásra kerül, és az adatok visszakerülnek.


A frissítő tokenek megvalósításával a Tulip a tokenek lejáratának és megújításának intelligens kezelésével zökkenőmentesebb felhasználói élményt biztosít, minimalizálva a munkafolyamatok megszakadását.


## További olvasnivalók


* [Bevezetés a Tulip Connector Hostokba](/r230/docs/introduction-to-tulip-connector-hosts-1)
* [Csatlakozó pillanatképek készítése](/r230/docs/connector-snapshotting)
* [Az OAuth2.0 magyarázata](/r230/docs/oauth20-explained)

Hasznos volt ez a cikk?

What's Next

Hogyan futtassunk egy csatlakozófunkciót több környezetben?

Tartalomjegyzék

Tulip engedélyezési kód áramlás