- Wydrukować
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:
- Użytkownik inicjuje przepływ, klikając przycisk Test przed zapisaniem Connectora.
- 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.
- Serwer autoryzacji prosi użytkownika o przyznanie dostępu, jak pokazano poniżej:
- Po uzyskaniu zgody użytkownika serwer autoryzacji generuje kod autoryzacji i zamyka okno uwierzytelniania.
- 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.
- Po zweryfikowaniu kodu autoryzacji serwer odpowiada tokenem i opcjonalnie tokenem odświeżania. Ten token służy do autoryzowanych przez użytkownika żądań.
- 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.
- Użytkownik inicjuje przepływ, klikając przycisk Test przed zapisaniem Connectora.
- 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.
- 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ń.
- 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 nalogowanie
, 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: