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.

Typy uwierzytelniania

Tulip obsługuje trzy typy uwierzytelniania OAuth2.0: OAuth2.0 (konto usługi), OAuth2.0 (poświadczenia użytkownika) i OAuth2.0 (poświadczenia klienta). Kluczowe rozróżnienie polega na tym, w jaki sposób poświadczenia są współdzielone między użytkownikami i przepływem, który jest wykonywany zgodnie ze specyfikacją OAuth. Pełna lista i opis unikalnych przepływów OAuth są dostępne tutaj: https://frontegg.com/blog/oauth-flows.

:::(Info) (Uwaga)W starszych wersjach Tulip, OAuth2.0 (Konto usługi) było nazywane OAuth2 (Administrator), a OAuth2.0 (Poświadczenia użytkownika) było nazywane OAuth2 (Operator).:::

Przepływ kodu autoryzacji:

• OAuth2.0 (Konto usługi): Używa poświadczeń dostarczonych podczas testowania konektora dla wszystkich użytkowników w Tulip Player. Idealny dla współdzielonych poświadczeń w całej organizacji. Ponowne uwierzytelnienie administratora jest wymagane w przypadku wygaśnięcia poświadczeń.
• OAuth2.0 (poświadczenia użytkownika): 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.

Przepływ poświadczeń klienta:

• OAuth2.0 (Client Credentials): Ten typ dotacji jest używany przez Tulip do uzyskania tokena dostępu poprzez uwierzytelnienie na serwerze autoryzacji przy użyciu poświadczeń klienta (identyfikator klienta i sekret klienta), zazwyczaj w celu uzyskania dostępu do zasobów w imieniu własnym, a nie w imieniu użytkownika.

Odsłanianie podstaw

Przed zagłębieniem 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.

Przepływ kodu autoryzacji

:::(Warning) (Ostrzeżenie)Aby zakończyć proces uwierzytelniania użytkownika, przeglądarka musi zezwalać na wyskakujące okienka. Jeśli konektor jest skonfigurowany z wieloma środowiskami, każde środowisko otworzy osobne wyskakujące okienko podczas uwierzytelniania.

Jak sprawdzić, czy wyskakujące okienka są włączone w Chrome:

1. Otwórz przeglądarkę Chrome i kliknij menu z trzema kropkami w prawym górnym rogu okna.
2. Wybierz Ustawienia z rozwijanego menu.
3. Przewiń w dół i kliknij Prywatność i bezpieczeństwo.
4. W sekcji "Prywatność i bezpieczeństwo" kliknij Ustawienia witryny.
5. Przewiń w dół i kliknij Wyskakujące okienka i przekierowania.
6. Upewnij się, że przełącznik jest ustawiony na zezwalanie na wyskakujące okienka lub ręcznie dodaj witrynę do listy witryn, które mogą wyświetlać wyskakujące okienka.

Jeśli wyskakujące okienka są zablokowane, Chrome wyświetli małą ikonę na pasku adresu za każdym razem, gdy wyskakujące okienko zostanie zablokowane. Możesz kliknąć tę ikonę, aby szybko zezwolić na wyskakujące okienka z Tulip:

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 autoryzacyjny, Tulip bezpiecznie żąda tokena, docierając do punktu końcowego tokena, podając kod autoryzacyjny, 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.

Zobacz poniższe diagramy, aby zrozumieć ścieżkę wykonania:

Przepływ poświadczeń klienta

Przepływ poświadczeń klienta jest używany głównie do interakcji dwóch systemów biznesowych. Ten przepływ jest konfigurowany raz, a następnie współdzielony przez wszystkich użytkowników.

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 zwraca token dostępu, zakładając, że Client ID i Client Secret są dokładne. Opcjonalnie można również zwrócić token 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.

Konfigurowanie OAuth

:::(Warning) (On-Prem Services)Punkty końcowe Authorize i Token muszą być dostępne dla chmury, aby Tulip mógł wykonać uwierzytelnianie dla konektorów.:::

Authorization Code URL

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.

Uwaga: To pole nie jest obecne dla poświadczeń klienta.

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. Zwykle kończy się na /token.

Uwaga: To pole nie jest obecne dla poświadczeń klienta.

Identyfikator klienta i klucz tajny klienta

Generowany z interfejsu użytkownika dostawcy OAuth, identyfikator klienta jest przekazywany wraz z początkowym żądaniem kodu autoryzacji. Identyfikator klienta i klucz tajny klienta towarzyszą wszystkim żądaniom tokenów.

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. Obie te informacje są przekazywane podczas żądania kodu autoryzacji w kroku 2.

Dodatkowe opcje

• Wyślij dane żądania tokenu jako JSON: Zmienia typ kodowania żądania wysyłanego do adresu URL tokenu. Włącz w razie potrzeby dla określonych integracji.
• Wyślij nagłówek uwierzytelniania dla żądania odświeżenia: Po włączeniu dodaje dodatkowy nagłówek do żądań odświeżenia.
• Skip User Consent Prompt: Kontroluje atrybut monitu żądania kodu uwierzytelniającego. 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