Forbindelser (per-bruger OAuth2)
Forbindelser er, hvordan en individuel bruger giver AiHummer adgang til en tredjepartstjeneste på egne vegne. I stedet for en enkelt delt servicekonto, kører hver person en standard OAuth2 autorisationskode-flow, det resulterende token er forseglet i det krypterede hvælving, og når det bliver tid, løser runtime den pågældende brugers token, når et værktøj har brug for det.
Dette er den “personlige” del af AiHummers legitimationsmodel. For det bredere billede — hvornår man bør foretrække en delt legitimationsoplysning, og hvordan fallback fungerer — se Personlige vs delte legitimationsoplysninger.
Hvad en forbindelse er
En forbindelse binder tre ting sammen: en udbyder (den OAuth2-app, du godkender imod), en bruger (den person, der udfyldte samtykkeskærmen), og en boksindgang (hvor den udstedte token er gemt). Når det først er etableret, kan ethvert værktøj, der handler på vegne af den bruger, gennemsigtigt bruge token uden at det nogensinde vises i modelkonteksten, i logfiler eller i prompten.
Forbindelser administreres fra administratorbrugergrænsefladen. Listen viser hver brugers tilknyttede udbydere, deres status og hvornår de sidst blev opdateret.
Autoriseringskode-flowet
En forbindelse oprettes med den kanoniske trebenede OAuth2-autoriseringskode-godkendelse:
- Brugeren starter en forbindelse til en udbyder fra admin-UI’en — en
POST/GET /v1/admin/connections/oauth/startanmodning. - AiHummer videresender browseren til udbyderen autorisation endepunkt med de ønskede scopes.
- Brugeren godkender samtykkeskærmen; udbyderen omdirigerer tilbage med en
engangs autorisationkode til
/v1/admin/connections/oauth/callback. - Inde i callback-handleren udveksler AiHummer den kode server-side for en adgangstoken (og, når udbyderen understøtter det, en opdaterings-token) ved udbyderens token-endpoint.
- Tokenet skrives til hvelvet, og forbindelsen markeres som aktiv.
Kode-for-token-udvekslingen sker server-side inde i callbacken, så klienthemmeligheden og den udstedte token aldrig forlader gatewayen.
[!NOTE] Forveksl ikke denne strøm med
POST /v1/oauth/token: det er AiHummers egen OAuth2-klient-legitimationsendepunkt — servicekonti registreret via/v1/admin/apikeys/register-clientudveksle deresclient_id/client_secretder for en kortvarigah-token. Det har intet at gøre med tredjepart Forbindelser.
[!NOTE] Autoriseringskodeflowet involverer altid et rigtigt browser-samtykketrin. A Forbindelse kan ikke oprettes uden hoved fra en API-nøgle alene — den handlende bruger skal godkende omfangene én gang.
Hvor tokenen bor
Det udstedte token gemmes i AiHummer’s krypteret legitimationsopbevaring, ikke i almindelig konfiguration. Hvælvet bruger kuvertkryptering (AES-256-GCM med en datanøgle pr. lejer under en hovednøgle), og hemmeligheder kopieres aldrig ind i modelkonteksten, prompts eller logfiler. En tilbagekaldt eller udløbet forbindelse efterlader simpelthen ingen brugbar hemmelighed.
oauth/start ─▶ consent ─▶ code ─▶ oauth/callback (exchange at the provider) ─▶ access/refresh token ─▶ vault (encrypted)Løst af den handlende bruger
Den afgørende egenskab ved en forbindelse er, at den er løst af den fungerende bruger. Når en agent kører et værktøj, der har brug for udbyderen, leder runtime-miljøet efter den Connection, der tilhører den bruger, som turen kører på vegne af, og bruger deres token. To ansatte, der taler med den samme agent, handler derfor med deres egne tilladelser og ser kun, hvad deres egen godkendelse tillader.
Dette er det, der gør Connections velegnet til personlige, per-bruger integrationer: hver persons adgang er isoleret, reviderbar og individuelt tilbagekaldelig.
Tilgængelige integrationer
Gennem OAuth2-flowet kan en bruger forbinde deres egen konto til enhver af forsendelsestjenesterne. Disse personlige integrationer er tilgængelige direkte:
| Gruppe | Tjenester |
|---|---|
| Gmail, Google Kalender, Google Kontakter, Google Opgaver, Google Drev, YouTube | |
| Microsoft | Outlook Mail, Outlook Kalender, OneDrive, Microsoft To Do |
| Produktivitet | Todoist, Asana, Jira Cloud, ClickUp, GitLab, Linear, monday.com |
| Sundhed og livsstil | Fitbit, Oura Ring, Strava, Spotify, Samsung SmartThings |
Hver enkelt forbinder med den samme autorisationskode-flow: brugeren gennemfører udbyderens samtykkeskærm, tokenet bliver forseglet i kassen, og det bliver løst for den bruger, hver gang et værktøj tilgår tjenesten.
Administrere forbindelser i admin-brugerfladen
Fra admin-brugergrænsefladen kan en operatør:
- Se hvilke udbydere hver bruger har tilsluttet, og helbredet for hver token.
- Start en ny forbindelse (starter samtykkeforløbet for en valgt udbyder).
- Tilbagekald en forbindelse, som fjerner hvelvposten og deaktiverer opløsning.
Forbindelser er enten personlig (ejet af en bestemt bruger, som kan afbryde dem) eller delt med arbejdsområdet (mærket “Workspace delt”; de kan ikke kobles fra personligt). Én udbyder kan holde flere konti: knappen “+ konto” beder om en etiket og gemmer en anden legitimation fra samme udbyder — f.eks. flere Google-kalendere eller postkasser.
Fordi de underliggende legitimationsoplysninger er personlige, er en forbindelse oftest det rigtige værktøj, når en handling skal tilskrives og begrænses af en specifik persons autorisation snarere end en arbejdsområdes-bred konto.
Hvor til næste
- Personlige vs delte legitimationsoplysninger — den fulde omfangsmodel og hvornår man skal vælge hver.
- BYOK LLM-udbydere — medbring dine egne modelnøgler pr. lejer.
- Markedspladsoversigt og niveauer — hvor OAuth-baserede integrationer passer.