Konfiguracja i szczegóły techniczne OAuth2.0

W tym artykule zagłębimy się w szczegóły techniczne tego, jak Tulip implementuje OAuth do uwierzytelniania konektorów. OAuth jest potężny, ale wiąże się z pewną dodatkową złożonością. Ten przewodnik ma na celu odpowiedzieć na wszelkie pytania techniczne dotyczące tego, co obsługuje Tulip i jak jest zintegrowany.

Uwaga: Przepływ poświadczeń klienta różni się nieco od przepływu kodu autoryzacji. Kroki 1 i 2 nie są istotne dla przepływu poświadczeń klienta.

Przepływ kodu autoryzacji Tulip

:::(Warning) (Usługi lokalne) Punkty końcowe Authorize i Token muszą być dostępne dla chmury, aby Tulip mógł wykonać uwierzytelnianie dla łączników :::

Tulip inicjuje proces uwierzytelniania podczas testowania konektora lub uruchamiania funkcji konektora w aplikacji.

1. Przekierowanie do serwera autoryzacji:

Aplikacja Tulip przekierowuje użytkownika do serwera autoryzacji (AS) wraz z określonymi parametrami, w tym response_type (ustawiony na "code" dla Authorization Code Flow), client_id (przypisany w interfejsie użytkownika konektora), redirect_uri (predefiniowany przez Tulip), scope i audience (ustawione w interfejsie użytkownika) oraz state (losowy ciąg znaków w celu ochrony przed atakami Cross-Site Request Forgery).

Przykład:GET /authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=SCOPE&audience=AUDIENCE&state=STATE

2. Użytkownik udziela zgody:

Serwer autoryzacji uwierzytelnia użytkownika i przedstawia mu ekran zgody. Użytkownik może przejrzeć żądane uprawnienia i zdecydować, czy udzielić, czy odmówić dostępu do aplikacji innej firmy.

:::(Warning) (Uwaga) W ramach konfiguracji łącznika give kontrolka "Skip user consent prompt" pozwala kontrolować atrybut prompt w żądaniu autoryzacji. Gdy ta kontrolka jest wyłączona, zostanie użyta wartość zgody, gdy jest włączona, zostanie użyty login.

Jeśli wymagane są dodatkowe wartości atrybutu prompt, skontaktuj się z support@tulip.co, a my włączymy dodatkowe opcje dla tej właściwości :::

3. Kod autoryzacji:

Jeśli użytkownik wyrazi zgodę, serwer autoryzacji generuje kod autoryzacji i przekierowuje użytkownika z powrotem do Tulip wraz z kodem autoryzacji. Parametr stanu jest również dołączony, umożliwiając klientowi weryfikację integralności odpowiedzi. Ten parametr stanu musi być zgodny z parametrem stanu przekazanym w kroku 1.

Przykładowe przekierowanie do URI przekierowania klienta:

REDIRECT_URI?code=AUTHORIZATION_CODE&state=STATE

4. Żądanie tokena:

Klient ma teraz kod autoryzacji i używa go do wykonania bezpiecznego żądania serwer-serwer do punktu końcowego tokena serwera autoryzacji. Klient zawiera grant_type (ustawiony na "authorization_code"), client_id, client_secret (sekret znany tylko klientowi i serwerowi autoryzacji), redirect_uri i kod autoryzacji.

Przykładowe żądanie tokena:

`` POST /token 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. Odpowiedź tokena dostępu:

Jeśli kod autoryzacji jest prawidłowy, serwer autoryzacji odpowiada tokenem dostępu i, opcjonalnie, tokenem odświeżania. Token dostępu jest używany przez klienta do uwierzytelniania się podczas wykonywania żądań do chronionego interfejsu API w imieniu użytkownika.

Przykładowa odpowiedź tokena:

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

6. Uzyskiwanie dostępu do serwera zasobów:

Tulip może teraz użyć uzyskanego tokena dostępu do wykonywania autoryzowanych żądań do serwera zasobów (API) w imieniu użytkownika. Token dostępu jest zwykle zawarty w nagłówku Authorization żądania HTTP.

Przykładowe żądanie API:GET /api/resource Authorization: Bearer ACCESS_TOKEN

Zarządzanie wygaśnięciem tokenu za pomocą tokenów odświeżania

Serwery autoryzacji zazwyczaj ustawiają daty wygaśnięcia tokenów w celu regulowania dostępu, z różnymi oknami wygaśnięcia w zależności od połączonego systemu. Jednak krótkotrwałe tokeny stanowią wyzwanie, ponieważ ciągłe uwierzytelnianie użytkownika zakłóca doświadczenie użytkownika w aplikacjach Tulip.

Aby rozwiązać ten problem, OAuth obsługuje tokeny odświeżania. Chociaż są one opcjonalne, są wysoce zalecane, ponieważ usprawniają doświadczenie użytkownika, umożliwiając Tulip płynne odświeżanie tokenów bez konieczności ręcznego wprowadzania danych przez operatorów.

Jak Tulip zarządza odświeżaniem tokenów

Gdy Tulip wykryje, że token dostępu wygasł, automatycznie próbuje użyć powiązanego tokena odświeżania, aby uzyskać nowy token. Głównym celem jest zminimalizowanie ponownego uwierzytelniania użytkowników. Poniższe kroki przedstawiają logikę wykonywaną przez Tulip:

1. Wykrywanie wygaśnięcia:

2. Tulip identyfikuje wygasły token na podstawie jego atrybutu expires_in otrzymanego w kroku 5 przepływu uwierzytelniania.

3. Próba przepływu tokenu:

4. Tulip inicjuje przepływ tokena przy użyciu typu grantu refresh_token, zastępując typ grantu authorization_code użyty w początkowym przepływie uwierzytelniania.

5. Token Validation:

6. Jeśli nowy token zostanie uzyskany, Tulip przechowuje go i przystępuje do wykonania żądanej przez użytkownika funkcji łącznika.

   • Jeśli się powiedzie, dane są dostarczane do środowiska wykonawczego aplikacji Tulip.
   • Jeśli nowy token nie powiedzie się z błędem OAuth, Tulip ponawia proces do 5 razy, powracając do kroku 1 za każdym razem.
   • Jeśli nowy token nie powiedzie się z jakimkolwiek innym błędem, błąd zostanie wyświetlony w środowisku wykonawczym odtwarzacza.

7. Obsługa braku tokena:

8. Jeśli nowy token nie zostanie dostarczony, Tulip wyświetli monit o uwierzytelnienie użytkownika w odtwarzaczu, inicjując cały proces uwierzytelniania.

9. Po zakończeniu wykonywana jest funkcja konektora i zwracane są dane.

Wdrażając tokeny odświeżania, Tulip zapewnia płynniejsze doświadczenie użytkownika poprzez inteligentne zarządzanie wygaśnięciem i odnowieniem tokena, minimalizując zakłócenia w przepływie pracy.

Więcej informacji

• Wprowadzenie do hostów konektorów Tulip
• Migawki konektorów
• Wyjaśnienie OAuth2.0