Anslutningar (per-användare OAuth2)
Kontakter är hur en enskild användare ger AiHummer åtkomst till en tredjepartstjänst på egen vägnar. Istället för ett enda delat tjänstekonto kör varje person en standard OAuth2-auktoriseringskodflöde, den resulterande token är förseglad i det krypterade valvet, och vid turtid löser körningen den användarens token när ett verktyg behöver det.
Detta är den “personliga” halvan av AiHummers autentiseringsmodell. För den bredare bilden – när man bör föredra en delad autentisering och hur fallback fungerar – se Personliga vs delade autentiseringsuppgifter.
Vad en anslutning är
En anslutning binder tre saker tillsammans: en leverantör (OAuth2-appen som du auktoriserar mot), en användare (personen som fyllde i samtyckesskärmen), och en valvinskrift (där den utfärdade token lagras). När det väl är etablerat kan vilket verktyg som helst som agerar på uppdrag av den användaren transparent använda token utan att det någonsin visas i modellens kontext, i loggar eller i prompten.
Anslutningar hanteras från administrationsgränssnittet. Listan visar varje användares anslutna leverantörer, deras status och när de senast uppdaterades.
Autentiseringskodflödet
En anslutning skapas med den kanoniska trestegs OAuth2-auktoriseringskodgrantet:
- Användaren startar en anslutning för en leverantör från administrationsgränssnittet — en
POST/GET /v1/admin/connections/oauth/startbegäran. - AiHummer omdirigerar webbläsaren till leverantörens auktorisation ändpunkt med de begärda områdena.
- Användaren godkänner samtyckesskärmen; leverantören omdirigerar tillbaka med en
engångs auktoriseringskod till
/v1/admin/connections/oauth/callback. - Inuti callback-hanteraren byter AiHummer den koden på serversidan mot en åtkomsttoken (och, när leverantören stöder det, en uppdateringstoken) på leverantörens token-slutpunkt.
- Tokenet skrivs till valvet och anslutningen markeras som aktiv.
Kod-för-token-utbytet sker på serversidan inuti callbacken, så klienthemligheten och den utfärdade tokenen lämnar aldrig gatewayen.
[!NOTE] Förväxla inte detta flöde med
POST /v1/oauth/token: det är AiHummers äga OAuth2-klientuppgifter-endpoint — tjänstekonton registrerade via/v1/admin/apikeys/register-clientbyter derasclient_id/client_secretdär för en kortlivadah-token. Det har inget att göra med tredje part Anslutningar.
[!NOTE] Auktoriseringskodsflödet involverar alltid ett riktigt webbläsarsamtyckessteg. A Anslutning kan inte skapas utan huvud från enbart en API-nyckel — den agerande användaren måste godkänna behörigheterna en gång.
Var tokenen finns
Den utfärdade token lagras i AiHummer’s krypterad behörighetsvalv, inte i vanlig konfiguration. Valvet använder kuvertkryptering (AES-256-GCM med en data-nyckel per hyresgäst under en huvudnyckel), och hemligheter kopieras aldrig in i modellens kontext, prompts eller loggar. En återkallad eller utgången anslutning lämnar helt enkelt ingen användbar hemlighet kvar.
oauth/start ─▶ consent ─▶ code ─▶ oauth/callback (exchange at the provider) ─▶ access/refresh token ─▶ vault (encrypted)Löst av den tillfälligt ansvariga användaren
Den avgörande egenskapen hos en anslutning är att den är lösts av den tillförordnade användaren. När en agent använder ett verktyg som behöver leverantören, letar körmiljön upp den Anslutning som tillhör användaren för vilken turen körs, och använder hennes/hans token. Två anställda som pratar med samma agent agerar därför med sina egna behörigheter och ser endast vad deras egen behörighet tillåter.
Detta är det som gör Connections lämpligt för personliga, per-användar-integrationer: varje persons åtkomst är isolerad, granskningsbar och individuellt återkallelig.
Tillgängliga integrationer
Genom OAuth2-flödet kan en användare ansluta sitt eget konto till vilken av frakttjänsterna som helst. Dessa personliga integrationer är tillgängliga direkt:
| Grupp | Tjänster |
|---|---|
| Gmail, Google Kalender, Google Kontakter, Google Uppgifter, Google Drive, YouTube | |
| Microsoft | Outlook Mail, Outlook Kalender, OneDrive, Microsoft Att Göra |
| Produktivitet | Todoist, Asana, Jira Cloud, ClickUp, GitLab, Linear, monday.com |
| Hälsa och livsstil | Fitbit, Oura Ring, Strava, Spotify, Samsung SmartThings |
Var och en ansluter med samma auktoriseringskodflöde: användaren slutför leverantörens samtyckesskärm, tokenen förseglas i valvet, och den löses upp för den användaren varje gång ett verktyg når tjänsten.
Hantera anslutningar i administrationsgränssnittet
Från administrationsgränssnittet kan en operatör:
- Se vilka leverantörer varje användare har kopplat och hälsan på varje token.
- Starta en ny anslutning (starta samtyckesflödet för en vald leverantör).
- Återkalla en anslutning, vilket tar bort valvposten och inaktiverar upplösning.
Anslutningar är antingen personal (ägt av en viss användare, som kan koppla från dem) eller delat med arbetsytan (markerad “Workspace delad”; de kan inte kopplas bort personligen). En leverantör kan hålla flera konton: knappen ”+ konto” frågar efter en etikett och lagrar ännu en uppgift från samma leverantör — t.ex. flera Google-kalendrar eller e-postlådor.
Eftersom de underliggande autentiseringsuppgifterna är personliga är en anslutning oftast det rätta verktyget när en åtgärd måste tillskrivas och begränsas av en viss människas auktorisation snarare än ett konto för hela arbetsytan.
Vart härnäst
- Personliga vs delade autentiseringsuppgifter — den fullständiga omfattningsmodell och när man ska välja varje.
- BYOK LLM-leverantörer — ta med dina egna modellnycklar per hyresgäst.
- Marknadsöversikt och nivåer — var OAuth-baserade integrationer passar.