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

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

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

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 állítva), a client_id (a csatlakozó felhasználói felületén hozzárendelve), a redirect_uri (a Tulip által előre meghatározott), a scope és a audience (a felhasználói felületen állítva), valamint 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.

:::(Warning) (Megjegyzés) Az adáscsatlakozó konfigurációján belül a "Skip user consent prompt" (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:

kód=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:

Content-Type: application/x-www-form-urlencoded

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" }

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

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/resource Authorization: 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ál a hozzá tartozó frissítési token segítségével új tokent szerezni. 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:

1. Lejárat észlelése:

2. A Tulip a hitelesítési folyamat 5. lépésében kapott expires_in attribútum alapján azonosítja a lejárt tokent.

3. Token-áramlási kísérlet:

4. A Tulip kezdeményezi a token-áramlást a refresh_token adattípus használatával, a kezdeti hitelesítési folyamatként használt authorization_code adattípus helyett.

5. Token érvényesítés:

6. Ha új token érkezik, a Tulip tárolja azt, és végrehajtja a felhasználó által kért csatlakozó funkció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.

7. Token hiányának kezelése:

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

9. 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
• Csatlakozó pillanatképek készítése
• Az OAuth2.0 magyarázata