Połączenia (OAuth2 dla użytkownika)
Połączenia są tym, jak indywidualny użytkownik udziela AiHummer dostępu do usługi zewnętrznej we własnym imieniu. Zamiast jednego wspólnego konta usługowego, każda osoba korzysta ze standardowego Przepływ autoryzacji OAuth2 z kodem, powstały token jest zapieczętowany w zaszyfrowanym sejfie, a w czasie wykonywania środowisko uruchomieniowe rozwiązuje token tego użytkownika, gdy narzędzie go potrzebuje.
To jest „osobista” część modelu poświadczeń AiHummera. Dla szerszego obrazu — kiedy warto używać wspólnego poświadczenia i jak działa mechanizm awaryjny — zobacz Osobiste vs wspólne dane uwierzytelniające.
Czym jest połączenie
Połączenie wiąże trzy rzeczy razem: a dostawca (aplikacja OAuth2, której udzielasz autoryzacji), a użytkownik (osoba, która wypełniła ekran zgody), i wejście do skarbca (gdzie przechowywany jest wydany token). Po jego ustaleniu każde narzędzie działające w imieniu tego użytkownika może przejrzyście korzystać z tokena, bez jego pojawiania się w kontekście modelu, w logach ani w promptach.
Połączeniami zarządza się z poziomu panelu administracyjnego. Lista pokazuje podłączonych dostawców dla każdego użytkownika, ich status oraz kiedy ostatnio zostały odświeżone.
Przepływ z kodem autoryzacyjnym
Połączenie jest nawiązywane przy użyciu kanonicznego, trzyetapowego udzielania kodu autoryzacyjnego OAuth2:
- Użytkownik rozpoczyna połączenie dla dostawcy z poziomu interfejsu administracyjnego — a
POST/GET /v1/admin/connections/oauth/startprośba. - AiHummer przekierowuje przeglądarkę do dostawcy autoryzacja punkt końcowy z żądanymi zakresami.
- Użytkownik zatwierdza ekran zgody; dostawca przekierowuje z powrotem z
jednorazowy kod autoryzacyjny do
/v1/admin/connections/oauth/callback. - Wewnątrz obsługi wywołania zwrotnego, AiHummer wymienia ten kod po stronie serwera na token dostępu (i, gdy dostawca to obsługuje, a token odświeżania) w punkcie końcowym tokena dostawcy.
- Token jest zapisany w sejfie, a połączenie oznaczone jako aktywne.
Wymiana kodu na token odbywa się po stronie serwera w ramach wywołania zwrotnego, więc sekret klienta i wydany token nigdy nie opuszczają bramki.
[!NOTE] Nie myl tego przepływu z
POST /v1/oauth/token: to jest AiHummera własny Punkt końcowy OAuth2 client-credentials — konta usług zarejestrowane za pomocą/v1/admin/apikeys/register-clientwymienić ichclient_id/client_secrettam na krótkoah-token. Nie ma to nic wspólnego z podmiotami trzecimi Połączenia.
[!NOTE] Proces przepływu kodu autoryzacyjnego zawsze wiąże się z rzeczywistym krokiem zgody w przeglądarce. A Połączenie nie może być utworzone w trybie bezgłowym wyłącznie za pomocą klucza API — działający użytkownik musi zatwierdzić zakresy raz.
Gdzie token się znajduje
Wydany token jest przechowywany w AiHummer zaszyfrowany sejf na dane uwierzytelniające, nie w zwykłej konfiguracji. Skarbiec używa szyfrowania kopertowego (AES-256-GCM z kluczem danych dla każdego najemcy przechowywanym pod kluczem głównym), a tajne dane nigdy nie są kopiowane do kontekstu modelu, promptów ani logów. Cofnięte lub wygasłe Połączenie po prostu nie pozostawia żadnej użytecznej tajemnicy.
oauth/start ─▶ consent ─▶ code ─▶ oauth/callback (exchange at the provider) ─▶ access/refresh token ─▶ vault (encrypted)Rozwiązane przez działającego użytkownika
Definiującą cechą połączenia jest to, że jest rozwiązane przez działającego użytkownika. Kiedy agent uruchamia narzędzie, które potrzebuje dostawcy, środowisko wykonawcze wyszukuje Połączenie należące do użytkownika, w imieniu którego wykonywana jest tura, i używa jego tokenu. Dwóch pracowników rozmawiających z tym samym agentem działa więc na podstawie własnych uprawnień i widzi tylko to, na co pozwala ich własne zezwolenie.
To właśnie sprawia, że Connections nadaje się do osobistych, indywidualnych integracji: dostęp każdej osoby jest izolowany, możliwy do audytu i indywidualnie odwoływalny.
Dostępne integracje
Poprzez przepływ OAuth2 użytkownik może połączyć swoje własne konto z dowolną z usług wysyłkowych. Te osobiste integracje są dostępne od razu:
| Grupa | Usługi |
|---|---|
| Gmail, Kalendarz Google, Kontakty Google, Zadania Google, Dysk Google, YouTube | |
| Microsoft | Poczta Outlook, Kalendarz Outlook, OneDrive, Microsoft To Do |
| Produktywność | Todoist, Asana, Jira Cloud, ClickUp, GitLab, Linear, monday.com |
| Zdrowie i styl życia | Fitbit, Oura Ring, Strava, Spotify, Samsung SmartThings |
Każdy z nich łączy się przy użyciu tego samego przepływu kodu autoryzacyjnego: użytkownik wypełnia ekran zgody dostawcy, token jest zabezpieczany w sejfie i jest dostępny dla tego użytkownika za każdym razem, gdy narzędzie łączy się z usługą.
Zarządzanie połączeniami w interfejsie administracyjnym
Z poziomu interfejsu administracyjnego operator może:
- Zobacz, z którymi dostawcami każdy użytkownik jest połączony i jaki jest stan każdego tokena.
- Rozpocznij nowe połączenie (uruchamiając proces zgody dla wybranego dostawcy).
- Cofnij połączenie, co usuwa wpis w sejfie i wyłącza rozwiązywanie.
Połączenia są albo osobisty (należy do konkretnego użytkownika, który może je rozłączyć) lub udostępnione w obszarze roboczym (oznaczone „Udostępnione w przestrzeni roboczej”; nie mogą być odłączone osobiście). Jeden dostawca może posiadać wiele kont: przycisk „+ konto” prosi o etykietę i przechowuje kolejne poświadczenie tego samego dostawcy — np. kilka kalendarzy Google lub skrzynek mailowych.
Ponieważ podstawowe poświadczenia są osobiste, Połączenie jest najczęściej odpowiednim narzędziem, gdy akcja musi być przypisana do konkretnej osoby i ograniczona przez jej autoryzację, a nie przez konto obejmujące całe środowisko robocze.
Dokąd dalej
- Osobiste vs wspólne dane uwierzytelniające — pełny model zakresu i kiedy wybrać każdy.
- Dostawcy LLM BYOK — przynieś własne klucze do modeli na najemcę.
- Przegląd rynku i poziomy — gdzie Integracje obsługiwane przez OAuth pasują.