Conexiuni (OAuth2 per utilizator) — AiHummer Documentație

Conexiuni arată cum un utilizator individual acordă AiHummer acces la un serviciu terț în numele său. În loc de un singur cont de serviciu partajat, fiecare persoană rulează un standard Fluxul codului de autorizare OAuth2, tokenul rezultat este sigilat în seiful criptat, iar la momentul rulării, timpul de execuție rezolvă tokenul acelui utilizator când un instrument are nevoie de el.

Aceasta este jumătatea „personală” a modelului de acreditare AiHummer. Pentru o imagine mai largă — când să preferați o acreditare partajată și cum funcționează soluția de rezervă — vedeți Date de autentificare personale vs partajate.

Ce este o conexiune

O Conexiune leagă trei lucruri împreună: un furnizor (aplicația OAuth2 împotriva căreia autorizați), un utilizator (persoana care a completat ecranul de consimțământ), și un intrare în seif (unde este stocat tokenul emis). Odată stabilit, orice instrument care acționează în numele acelui utilizator poate folosi tokenul în mod transparent fără ca acesta să apară vreodată în contextul modelului, în jurnale sau în prompt.

Conexiunile sunt gestionate din interfața de administrare. Lista arată furnizorii conectați ai fiecărui utilizator, starea acestora și când au fost reîmprospătate ultima dată.

Fluxul cu cod de autorizare

O conexiune este creată cu grantul de cod de autorizare OAuth2 canonic cu trei picioare:

Utilizatorul inițiază o conexiune pentru un furnizor din interfața de administrare — un POST/GET /v1/admin/connections/oauth/start cerere.
AiHummer redirecționează browserul către furnizor autorizare punct final cu domeniile solicitate.
Utilizatorul aprobă ecranul de consimțământ; furnizorul redirecționează înapoi cu un unic cod de autorizare către /v1/admin/connections/oauth/callback.
În interiorul handler-ului de callback, AiHummer schimbă acel cod pe partea de server pentru un token de acces (și, atunci când furnizorul îl suportă, un token de reîmprospătare) la punctul final de token al furnizorului.
Tokenul este scris în seif și Conexiunea este marcată ca activă.

Schimbul de cod pentru token are loc pe server, în interiorul callback-ului, astfel încât secretul clientului și tokenul emis nu părăsesc niciodată gateway-ul.

[!NOTE] Nu confunda acest flux cu POST /v1/oauth/token: că aparține lui AiHummer propriu Endpoint-ul OAuth2 pentru acreditivele clientului — conturi de serviciu înregistrate prin /v1/admin/apikeys/register-client schimbă-le client_id/client_secret acolo pentru o perioadă scurtă ah- token. Nu are legătură cu terțe părți Conexiuni.

[!NOTE] Fluxul cu cod de autorizare implică întotdeauna un pas de consimțământ printr-un browser real. A Conexiunea nu poate fi creată fără interfață doar dintr-o cheie API — utilizatorul care acționează trebuie să aprobe domeniile o singură dată.

Unde trăiește jetonul

Jetonul emis este stocat în AiHummer’s seif de acreditări criptate, nu în configurație simplă. Seiful folosește criptare tip plic (AES-256-GCM cu o cheie de date per chiriaș sub o cheie principală), iar secretele nu sunt niciodată copiate în contextul modelului, prompturi sau jurnale. O Conexiune retrasă sau expirată pur și simplu nu lasă niciun secret utilizabil în urmă.

oauth/start ─▶ consent ─▶ code ─▶ oauth/callback (exchange at the provider) ─▶ access/refresh token ─▶ vault (encrypted)

Rezolvat de utilizatorul care acționează

Proprietatea definitorie a unei Conexiuni este că este rezolvat de utilizatorul care acționează. Când un agent rulează un instrument care are nevoie de furnizor, motorul de execuție caută Conexiunea aparținând utilizatorului în numele căruia se desfășoară turnul și folosește tokenul lor. Astfel, doi angajați care vorbesc cu același agent acționează cu propriile lor autorizații și văd doar ceea ce permite propriul lor drept de acces.

Acesta este motivul pentru care Connections este potrivit pentru integrări personale, per utilizator: accesul fiecărei persoane este izolat, auditat și revocabil individual.

Integrări disponibile

Prin fluxul OAuth2, un utilizator își poate conecta propriul cont la oricare dintre serviciile de livrare. Aceste integrări personale sunt disponibile direct din fabrică:

Grup	Servicii
Google	Gmail, Google Calendar, Contacte Google, Google Tasks, Google Drive, YouTube
Microsoft	Mail Outlook, Calendar Outlook, OneDrive, Microsoft To Do
Productivitate	Todoist, Asana, Jira Cloud, ClickUp, GitLab, Linear, monday.com
Sănătate și stil de viață	Fitbit, Oura Ring, Strava, Spotify, Samsung SmartThings

Fiecare se conectează folosind același flux de cod de autorizare: utilizatorul completează ecranul de consimțământ al furnizorului, tokenul este sigilat în seif și este valabil pentru acel utilizator ori de câte ori un instrument accesează serviciul.

Gestionarea conexiunilor în interfața de administrare

Din interfața de administrare, un operator poate:

Vezi ce furnizori a conectat fiecare utilizator și starea fiecărui token.
Pornește o conexiune nouă (inițiind fluxul de consimțământ pentru un furnizor ales).
Revocă o conexiune, ceea ce elimină intrarea din seif și dezactivează rezoluția.

Conexiunile sunt fie personal (deţinut de un utilizator specific, care îi poate deconecta) sau partajat cu spațiul de lucru (eticheta „Spațiu de lucru partajat”; nu pot fi deconectați personal). Un furnizor poate deține conturi multiple: butonul „+ cont” cere o etichetă și stochează o altă acreditare a aceluiași furnizor — de exemplu, mai multe calendare sau căsuțe poștale Google.

Deoarece acreditările subiacente sunt personale, o Conexiune este cel mai adesea instrumentul potrivit atunci când o acțiune trebuie atribuită și restricționată de autorizarea unui anumit individ, și nu de un cont la nivel de spațiu de lucru.

Unde următor?

Date de autentificare personale vs partajate — complet model de scop și când să alegi fiecare.
Furnizori LLM BYOK — adu-ți propriile chei pentru model pe chiriaș.
Prezentare generală a pieței și niveluri — unde Integrațiile susținute de OAuth se potrivesc.