Czym jest OAuth2.0?

Odkrywanie OAuth2.0

Witamy w eksploracji OAuth2.0, potężnego, ale często źle rozumianego protokołu uwierzytelniania w Tulip-verse. W tym artykule rozwikłamy podstawy, poprowadzimy Cię przez obsługiwane przez Tulip przepływy uwierzytelniania, objaśnimy konfigurację początkowego łącznika i podzielimy się szybkimi wskazówkami, aby zapewnić płynny start.

OAuth2.0 może być skomplikowany i aby zachować zwięzłość, pominęliśmy w tym artykule niektóre szczegółowe aspekty techniczne. Jeśli chcesz głębiej zagłębić się w obsługę tokenów odświeżania, zarządzanie zakresem i odbiorcami oraz niestandardowe konfiguracje konektorów, zalecamy zapoznanie się z tym szczegółowym przewodnikiem technicznym OAuth2.0.

Odsłanianie podstaw

Zanim zagłębimy się w szczegóły, sugerujemy zapoznanie się ze środowiskami i uzyskanie przeglądu hostów konektorów i ich funkcji.

OAuth2.0 służy jako mechanizm dla Tulip (klienta) do ustalenia swojej tożsamości z systemami biznesowymi. Dostęp jest przyznawany poprzez uścisk dłoni, a Tulip obsługuje przede wszystkim przepływ kodu autoryzacji, najpopularniejszy przepływ OAuth. Oto skondensowany przegląd tego, jak przebiega ten przepływ:

1. Użytkownik inicjuje przepływ, klikając przycisk Test przed zapisaniem Connectora.
2. Tulip komunikuje się z serwerem autoryzacji od dostawcy OAuth, udostępniając określone parametry, takie jak tożsamość klienta, zakresy (do czego próbujesz uzyskać dostęp) i inne istotne szczegóły.
3. Serwer autoryzacji prosi użytkownika o przyznanie dostępu, jak pokazano poniżej:

1. Po uzyskaniu zgody użytkownika serwer autoryzacji generuje kod autoryzacji i zamyka okno uwierzytelniania.
2. Uzbrojony w kod autoryzacji, Tulip bezpiecznie żąda tokena, docierając do punktu końcowego tokena, podając kod autoryzacji, identyfikator klienta, sekret klienta i dodatkowe właściwości.
3. Po zweryfikowaniu kodu autoryzacji serwer odpowiada tokenem i opcjonalnie tokenem odświeżania. Ten token służy do autoryzowanych przez użytkownika żądań.
4. Tulip może teraz wykonywać żądania w imieniu użytkowników, z dostarczonym tokenem do autoryzacji.

Konfiguracja OAuth

Przykładowa konfiguracja

Typy uwierzytelniania

Tulip obsługuje dwa typy uwierzytelniania OAuth2.0: Admin OAuth i Operator OAuth. Kluczowe rozróżnienie polega na sposobie udostępniania poświadczeń użytkownikom.

• OAuth (Admin): Używa poświadczeń dostarczonych podczas testowania konektora dla wszystkich użytkowników w Tulip Player. Idealny do współdzielenia poświadczeń w całej organizacji. Ponowne uwierzytelnienie administratora jest wymagane w przypadku wygaśnięcia poświadczeń.
• OAuth (Operator): Segmentuje uwierzytelnianie w oparciu o użytkownika zalogowanego do Tulip Player. Jeśli użytkownik nie uwierzytelnił się lub uwierzytelnienie wygasło, użytkownik przechodzi przepływ OAuth w Tulip Player.

Adres URL kodu autoryzacji

Jest to adres URL, z którym kontaktuje się Tulip w kroku 2 przepływu kodu uwierzytelniania. Znaleziony w dokumentacji API dostawcy OAuth, zazwyczaj kończy się na /auth lub /authorize.

Adres URL tokenu dostępu

Po odpowiedzi serwera autoryzacji wysyłane jest żądanie do adresu URL tokenu dostępu w celu uzyskania tokenu do uwierzytelnienia. Zazwyczaj kończy się na /token.

Identyfikator klienta i klucz tajny klienta

Wygenerowany z interfejsu użytkownika dostawcy OAuth, identyfikator klienta jest przekazywany wraz z początkowym żądaniem kodu uwierzytelniającego. Identyfikator klienta i klucz tajny klienta towarzyszą wszystkim żądaniom tokena.

Odbiorcy i zakres

Audience określa konkretne zasoby, do których użytkownik chce uzyskać dostęp, podczas gdy Scope definiuje pożądane działania na tych zasobach. Oba są przekazywane podczas żądania kodu autoryzacji w kroku 2.

Dodatkowe opcje

• Wyślij dane żądania tokena jako JSON: Zmienia typ kodowania żądania wysyłanego do adresu URL tokenu. Włączone w razie potrzeby dla określonych integracji.
• Wyślij nagłówek uwierzytelniania dla żądania odświeżenia: Dodaje dodatkowy Header do żądań odświeżenia, gdy jest włączony.
• Skip User Consent Prompt: Kontroluje atrybut monitu żądania Authentication Code. Wyłączony ustawia go na zgodę, podczas gdy włączony ustawia go na logowanie, pozwalając dostawcy OAuth zdecydować o wyświetleniu ekranu logowania.

:::(Warning) (Uwaga) W przypadku niektórych integracji należy wykluczyć lub ustawić atrybut prompt na none. Aby uzyskać więcej informacji, skontaktuj się z support@tulip.co :::

Więcej informacji

Chcesz uzyskać więcej informacji? Zapoznaj się z tymi artykułami:

• Konfiguracja OAuth2.0 i szczegóły techniczne
• Jak uruchomić funkcję konektora w wielu środowiskach