Tilkoblinger (per-bruker OAuth2)
Kontakter er hvordan en individuell bruker gir AiHummer tilgang til en tredjepartstjeneste på egne vegne. I stedet for en enkelt delt tjenestekonto, kjører hver person en standard OAuth2 autorisasjonskodeflyt, den resulterende tokenen blir forseglet i det krypterte hvelvet, og når det er tur, løser kjøretiden den brukerens token når et verktøy trenger det.
Dette er den “personlige” halvdelen av AiHummers autentiseringsmodell. For det større bildet — når man bør foretrekke en delt autentisering og hvordan reservealternativet fungerer — se Personlige vs delte legitimasjoner.
Hva en forbindelse er
En tilkobling binder tre ting sammen: en leverandør (OAuth2-appen du gir autorisasjon til), en bruker (personen som fullførte samtykkeskjermen), og en hvelvinngang (hvor det utstedte tokenet lagres). Når det er etablert, kan ethvert verktøy som handler på vegne av den brukeren, bruke tokenet transparent uten at det noen gang vises i modellens kontekst, i logger eller i prompten.
Tilkoblinger administreres fra administrasjonsgrensesnittet. Listen viser hver brukers tilkoblede leverandører, deres status og når de sist ble oppdatert.
Autorisasjonskodeflyt
En tilkobling opprettes med den kanoniske OAuth2-autorisasjonskode-godkjenningen med tre trinn:
- Brukeren starter en tilkobling for en leverandør fra administrasjonsgrensesnittet — en
POST/GET /v1/admin/connections/oauth/startforespørsel. - AiHummer videresender nettleseren til leverandørens autorisasjon endepunkt med de forespurte områdene.
- Brukeren godkjenner samtykkeskjermen; leverandøren omdirigerer tilbake med en
engangs autorisasjonskode til
/v1/admin/connections/oauth/callback. - Inne i tilbakekallingsbehandleren bytter AiHummer den koden server-side for en tilgangstoken (og, når leverandøren støtter det, en oppdateringstoken) på leverandørens token-endepunkt.
- Tokenet skrives til hvelvet og tilkoblingen merkes som aktiv.
Kode-for-token-utvekslingen skjer på serversiden inne i callbacken, så klienthemmeligheten og den utstedte tokenen forlater aldri gatewayen.
[!NOTE] Ikke forveksle denne strømmen med
POST /v1/oauth/token: det er AiHummers egen OAuth2-klient-legitimasjon-endepunkt — tjenestekontoer registrert via/v1/admin/apikeys/register-clientbytte deresclient_id/client_secretder for en kortvarigah-token. Det har ingenting å gjøre med tredjepart Forbindelser.
[!NOTE] Autorisasjonskodeflyten involverer alltid et ekte nettlesersamtykketrinn. A Tilkobling kan ikke opprettes uten en brukerhode kun fra en API-nøkkel alene — den handlende brukeren må godkjenne omfangene én gang.
Hvor tokenen bor
Det utstedte tokenet lagres i AiHummer’s kryptert legitimasjonsarkiv, ikke i vanlig konfigurasjon. Hvelvet bruker konvoluttkryptering (AES-256-GCM med en datas nøkkel per leietaker under en hovednøkkel), og hemmeligheter blir aldri kopiert inn i modellkontekst, forespørsler eller logger. En tilbakekalt eller utløpt tilkobling etterlater rett og slett ingen brukbar hemmelighet.
oauth/start ─▶ consent ─▶ code ─▶ oauth/callback (exchange at the provider) ─▶ access/refresh token ─▶ vault (encrypted)Løst av den midlertidige brukeren
Den definerende egenskapen til en tilkobling er at den er løst av den midlertidige brukeren. Når en agent kjører et verktøy som trenger tilbyderen, ser kjøretiden opp tilkoblingen som tilhører brukeren på hvis vegne handlingen kjøres, og bruker deres token. To ansatte som snakker med samme agent handler derfor med sine egne autorisasjoner og ser bare det som deres egen tillatelse gir dem tilgang til.
Dette er det som gjør Connections egnet for personlige, per-bruker-integrasjoner: hver persons tilgang er isolert, revisjonsbar og individuelt tilbakekallelig.
Tilgjengelige integrasjoner
Gjennom OAuth2-flyten kan en bruker koble sin egen konto til hvilken som helst av frakttjenestene. Disse personlige integrasjonene er tilgjengelige direkte:
| Gruppe | Tjenester |
|---|---|
| Gmail, Google Kalender, Google Kontakter, Google Oppgaver, Google Disk, YouTube | |
| Microsoft | Outlook Mail, Outlook-kalender, OneDrive, Microsoft To Do |
| Produktivitet | Todoist, Asana, Jira Cloud, ClickUp, GitLab, Linear, monday.com |
| Helse og livsstil | Fitbit, Oura Ring, Strava, Spotify, Samsung SmartThings |
Hver enkelt kobler til med den samme autorisasjonskodeflyten: brukeren fullfører leverandørens samtykkeskjerm, tokenet blir lagret i hvelvet, og det løses for den brukeren hver gang et verktøy når tjenesten.
Administrere tilkoblinger i administrasjonsgrensesnittet
Fra administrasjonsgrensesnittet kan en operatør:
- Se hvilke leverandører hver bruker har koblet til og helsen til hver token.
- Start en ny tilkobling (starter samtykkeflyten for en valgt leverandør).
- Opphev en tilkobling, som fjerner hvelvoppføringen og deaktiverer oppløsning.
Tilkoblinger er enten personlig (eid av en spesifikk bruker, som kan koble dem fra) eller delt med arbeidsområdet (merket “Workspace delt”; de kan ikke kobles fra personlig). Én leverandør kan holde flere kontoer: knappen «+ konto» ber om en etikett og lagrer en annen legitimasjon fra samme leverandør — f.eks. flere Google-kalendere eller postkasser.
Fordi de underliggende legitimasjonene er personlige, er en tilkobling oftest det rette verktøyet når en handling må tilskrives og begrenses av en bestemt persons autorisasjon fremfor en konto som gjelder hele arbeidsområdet.
Hvor til neste
- Personlige vs delte legitimasjoner — den fullstendige omfangsmodell og når man skal velge hver.
- BYOK LLM-leverandører — ta med dine egne modellnøkler per leietaker.
- Markedsplassoversikt og nivåer — hvor OAuth-baserte integrasjoner passer.