AiHummer
Deutsch▾
AnmeldenKonto
v1.2.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Zugriff und Integrationen/Verbindungen (pro Benutzer OAuth2)

Verbindungen (pro Benutzer OAuth2)

v1.2.x · aktualisiert 2026-07-05

Verbindungen sind, wie ein einzelner Benutzer AiHummer Zugang zu einem Drittanbieterdienst in seinem eigenen Namen gewährt. Anstatt eines einzelnen gemeinsamen Dienstkontos verwendet jede Person ein Standardkonto OAuth2-Autorisierungscode-Flow, das resultierende Token wird im verschlüsselten Tresor versiegelt, und zur Ausführungszeit löst die Laufzeit das Token dieses Benutzers auf, wenn ein Werkzeug es benötigt.

Dies ist die „persönliche“ Hälfte des Zugangsdatenmodells von AiHummer. Für das Gesamtbild – wann ein geteiltes Zugangsdaten bevorzugt werden sollte und wie die Rückfallsoption funktioniert – siehe Persönliche vs. geteilte Anmeldeinformationen.

Was eine Verbindung ist

Eine Verbindung bindet drei Dinge zusammen: eine Anbieter (die OAuth2-App, die Sie autorisieren), eine Benutzer (die Person, die den Einwilligungsbildschirm ausgefüllt hat), und ein Tresoreingang (wo das ausgestellte Token gespeichert wird). Sobald es etabliert ist, kann jedes Tool, das im Auftrag dieses Benutzers handelt, das Token transparent verwenden, ohne dass es jemals im Modellkontext, in Protokollen oder in der Eingabeaufforderung erscheint.

Verbindungen werden über die Admin-Benutzeroberfläche verwaltet. Die Liste zeigt die verbundenen Anbieter jedes Benutzers, deren Status und wann sie zuletzt aktualisiert wurden.

Der Autorisierungscode-Flow

Eine Verbindung wird mit dem kanonischen Drei-Bein-OAuth2-Autorisierungscode-Grant erstellt:

  1. Der Nutzer startet eine Verbindung für einen Anbieter über die Admin-Benutzeroberfläche — ein POST/GET /v1/admin/connections/oauth/start Anfrage.
  2. AiHummer leitet den Browser zum Anbieter weiter Genehmigung Endpunkt mit den angeforderten Berechtigungen.
  3. Der Benutzer genehmigt den Zustimmungsbildschirm; der Anbieter leitet zurück mit einem einmalig Autorisierungscode zu /v1/admin/connections/oauth/callback.
  4. Innerhalb des Callback-Handlers tauscht AiHummer diesen Code serverseitig gegen einen Zugangstoken (und, wenn der Anbieter dies unterstützt, ein Token aktualisieren) am Token-Endpunkt des Anbieters.
  5. Das Token wird in den Tresor geschrieben und die Verbindung wird als aktiv markiert.

Der Code-für-Token-Austausch findet serverseitig innerhalb des Callbacks statt, sodass das Client-Geheimnis und das ausgegebene Token die Gateway nie verlassen.

[!NOTE] Verwechseln Sie diesen Fluss nicht mit POST /v1/oauth/token: das gehört AiHummer eigen OAuth2-Client-Credentials-Endpunkt — Dienstkonten registriert über /v1/admin/apikeys/register-client ihre austauschen client_id/client_secret dort für eine kurze Zeit ah- Token. Es hat nichts mit Dritten zu tun Verbindungen.

[!NOTE] Der Autorisierungscode-Flow beinhaltet immer einen echten Browser-Zustimmungsschritt. A Verbindung kann nicht nur mit einem API-Schlüssel ohne Benutzer im Vordergrund erstellt werden — der handelnde Benutzer muss die Berechtigungen einmal genehmigen.

Wo das Token lebt

Das ausgegebene Token wird im AiHummer gespeichert verschlüsselter Anmeldeinformationen-Safe, nicht in einfacher Konfiguration. Der Tresor verwendet Umschlagverschlüsselung (AES-256-GCM mit einem pro-Mandanten-Datenschlüssel unter einem Hauptschlüssel), und Geheimnisse werden niemals in den Modellkontext, Aufforderungen oder Protokolle kopiert. Eine widerrufene oder abgelaufene Verbindung hinterlässt einfach kein verwendbares Geheimnis.

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

Vom handelnden Benutzer gelöst

Die bestimmende Eigenschaft einer Verbindung ist, dass sie ist vom handelnden Benutzer gelöst. Wenn ein Agent ein Werkzeug ausführt, das den Anbieter benötigt, sucht die Laufzeit die Verbindung des Benutzers, in deren Auftrag der Ablauf abläuft, und verwendet deren Token. Zwei Mitarbeiter, die mit demselben Agenten sprechen, handeln daher mit ihren eigenen Berechtigungen und sehen nur, was ihre eigene Genehmigung erlaubt.

Dies ist es, was Connections für persönliche, benutzerbezogene Integrationen geeignet macht: Der Zugang jeder Person ist isoliert, prüfbar und individuell widerrufbar.

Verfügbare Integrationen

Durch den OAuth2-Flow kann ein Benutzer sein eigenes Konto mit einem der Versanddienste verbinden. Diese persönlichen Integrationen sind sofort verfügbar:

Gruppe Dienstleistungen
Google Gmail, Google Kalender, Google Kontakte, Google Aufgaben, Google Drive, YouTube
Microsoft Outlook-Mail, Outlook-Kalender, OneDrive, Microsoft To Do
Produktivität Todoist, Asana, Jira Cloud, ClickUp, GitLab, Linear, monday.com
Gesundheit & Lebensstil Fitbit, Oura Ring, Strava, Spotify, Samsung SmartThings

Jeder verbindet sich mit demselben Autorisierungscode-Fluss: Der Benutzer durchläuft den Zustimmungsbildschirm des Anbieters, das Token wird im Tresor versiegelt, und es wird für diesen Benutzer aufgelöst, wann immer ein Tool den Dienst aufruft.

Verwaltung von Verbindungen in der Admin-Benutzeroberfläche

Von der Admin-Oberfläche aus kann ein Operator:

  • Sehen Sie, welche Anbieter jeder Benutzer verbunden hat und den Status jedes Tokens.
  • Starten Sie eine neue Verbindung (Einleitung des Einwilligungsprozesses für einen ausgewählten Anbieter).
  • Eine Verbindung widerrufen, die den Tresoreintrag entfernt und die Auflösung deaktiviert.

Verbindungen sind entweder persönlich (im Besitz eines bestimmten Benutzers, der sie trennen kann) oder mit dem Arbeitsbereich geteilt (markiert als “Workspace gemeinsam genutzt”; sie können nicht persönlich getrennt werden). Ein Anbieter kann halten mehrere Konten: die „+ Konto“-Schaltfläche fragt nach einer Bezeichnung und speichert eine weitere Anmeldeinformation desselben Anbieters — z. B. mehrere Google-Kalender oder Postfächer.

Da die zugrunde liegenden Zugangsdaten persönlich sind, ist eine Verbindung meist das richtige Werkzeug, wenn eine Aktion einer bestimmten Person zugeschrieben werden muss und durch deren Autorisierung beschränkt ist, anstatt durch ein arbeitsbereichsweites Konto.

Wohin als Nächstes