Conexiuni (OAuth2 per utilizator) — AiHummer Documentație

Conexiunile sunt modul în care un utilizator individual acordă AiHummer acces la un serviciu terț în numele său propriu. În loc de un singur cont de serviciu partajat, fiecare persoană rulează un flux OAuth2 standard cu cod de autorizare, tokenul rezultat este sigilat în seiful criptat, iar la momentul turei runtime-ul rezolvă tokenul acelui utilizator atunci când o unealtă are nevoie de el.

Aceasta este jumătatea “personală” a modelului de credențiale al AiHummer. Pentru imaginea mai amplă — când să preferați o credențială partajată și cum funcționează fallback-ul — consultați Credențiale personale vs partajate.

Ce este o Conexiune

O Conexiune leagă trei lucruri: un furnizor (aplicația OAuth2 față de care vă autorizați), un utilizator (persoana care a finalizat ecranul de consimțământ) și o intrare în seif (unde este stocat tokenul emis). Odată stabilită, orice unealtă care acționează în numele acelui utilizator poate folosi în mod transparent tokenul fără ca acesta să apară vreodată în contextul modelului, în loguri 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ătați ultima dată.

Fluxul cu cod de autorizare

O Conexiune este creată cu acordarea canonică OAuth2 cu cod de autorizare în trei etape:

Utilizatorul inițiază o conexiune pentru un furnizor din interfața de administrare.
AiHummer redirecționează browserul către endpointul de autorizare al furnizorului cu domeniile (scopes) solicitate.
Utilizatorul aprobă ecranul de consimțământ; furnizorul redirecționează înapoi cu un cod de autorizare de unică folosință.
AiHummer schimbă acel cod pentru un token de acces (și, atunci când furnizorul îl acceptă, un token de reîmprospătare) la endpointul de token al furnizorului.
Tokenul este scris în seif, iar Conexiunea este marcată ca activă.

Endpointul de token propriu al platformei este:

POST /v1/oauth/token

Acesta efectuează schimbul cod-pentru-token pe partea de server, astfel încât secretul clientului și tokenul emis să nu părăsească niciodată gateway-ul.

[!NOTE] Fluxul cu cod de autorizare implică întotdeauna un pas real de consimțământ în browser. O Conexiune nu poate fi creată fără interfață (head-less) doar dintr-o cheie API — utilizatorul care acționează trebuie să aprobe domeniile (scopes) o dată.

Unde se află tokenul

Tokenul emis este stocat în seiful de credențiale criptat al AiHummer, nu în configurație în text clar. Seiful folosește criptare de tip plic (AES-256-GCM cu o cheie de date per tenant sub o cheie master), iar secretele nu sunt niciodată copiate în contextul modelului, în prompturi sau în loguri. O Conexiune revocată sau expirată pur și simplu nu lasă în urmă niciun secret utilizabil.

consent ─▶ code ─▶ POST /v1/oauth/token ─▶ access/refresh token ─▶ vault (encrypted)

Rezolvată după utilizatorul care acționează

Proprietatea definitorie a unei Conexiuni este că este rezolvată după utilizatorul care acționează. Atunci când un agent rulează o unealtă care are nevoie de furnizor, runtime-ul caută Conexiunea aparținând utilizatorului în numele căruia rulează tura și folosește tokenul acestuia. Doi angajați care vorbesc cu același agent acționează, prin urmare, cu propriile lor autorizări și văd doar ceea ce permite propria lor acordare.

Acesta este motivul pentru care Conexiunile sunt potrivite pentru integrări personale, per utilizator: accesul fiecărei persoane este izolat, auditabil și revocabil individual.

Integrări disponibile

Prin fluxul OAuth2 un utilizator își poate conecta propriul cont la oricare dintre serviciile livrate. Aceste integrări personale sunt disponibile din start:

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

Fiecare se conectează cu același flux cu cod de autorizare: utilizatorul finalizează ecranul de consimțământ al furnizorului, tokenul este sigilat în seif și se rezolvă pentru acel utilizator ori de câte ori o unealtă accesează serviciul.

Gestionarea conexiunilor în interfața de administrare

Din interfața de administrare un operator poate:

Vedea ce furnizori a conectat fiecare utilizator și starea de sănătate a fiecărui token.
Iniția o nouă conexiune (lansând fluxul de consimțământ pentru un furnizor ales).
Revoca o conexiune, ceea ce elimină intrarea din seif și dezactivează rezolvarea.

Conexiunile pot fi personale (aparțin unui utilizator anume; el însuși le poate deconecta) sau partajate la nivel de workspace (marcate cu eticheta „Workspace shared”; nu pot fi deconectate personal). La un singur furnizor se pot lega mai multe conturi: butonul „+ cont” cere o etichetă (label) și salvează încă un cont al aceluiași furnizor — de exemplu, mai multe calendare Google sau căsuțe de email.

Deoarece credențialele subiacente sunt personale, o Conexiune este cel mai adesea unealta potrivită atunci când o acțiune trebuie atribuită unei autorizări a unui om anume și constrânsă de aceasta, mai degrabă decât unui cont la nivel de spațiu de lucru.

Unde mai departe

Credențiale personale vs partajate — modelul complet de domeniu și când să alegeți fiecare.
Furnizori LLM BYOK — aduceți-vă propriile chei de model per tenant.
Prezentare generală și niveluri Marketplace — unde se încadrează integrările bazate pe OAuth.