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 grantu jest używany przez Tulip do uzyskania tokena dostępu poprzez uwierzytelnienie z serwerem 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

Dostęp jest przyznawany poprzez uścisk dłoni, a Tulip obsługuje przede wszystkim Authorization Code Flow, najbardziej powszechny 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 w chmurze, 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