Connexions (OAuth2 par utilisateur)

Connexions sont comment un utilisateur individuel accorde à AiHummer l’accès à un service tiers en son propre nom. Au lieu d’un compte de service partagé unique, chaque personne utilise un standard Flux de code d’autorisation OAuth2, le jeton résultant est scellé dans le coffre crypté, et au moment de l’exécution, le runtime résout le jeton de cet utilisateur lorsqu’un outil en a besoin.

Ceci est la moitié « personnelle » du modèle d’identifiants d’AiHummer. Pour une vue d’ensemble — quand préférer un identifiant partagé et comment fonctionne le repli — voir Identifiants personnels vs partagés.

Ce qu’est une connexion

Une connexion relie trois choses entre elles : une fournisseur (l’application OAuth2 contre laquelle vous vous autorisez), un utilisateur (la personne qui a rempli l’écran de consentement), et un entrée du coffre (où le jeton émis est stocké). Une fois établi, tout outil agissant au nom de cet utilisateur peut utiliser le jeton de manière transparente sans qu’il n’apparaisse jamais dans le contexte du modèle, dans les journaux ou dans l’invite.

Les connexions sont gérées depuis l’interface d’administration. La liste montre les fournisseurs connectés de chaque utilisateur, leur statut et la date de leur dernière actualisation.

Le flux de code d’autorisation

Une connexion est créée avec le flux d’autorisation par code à trois étapes canonique d’OAuth2 :

L’utilisateur démarre une connexion pour un fournisseur depuis l’interface d’administration — un POST/GET /v1/admin/connections/oauth/start demande.
AiHummer redirige le navigateur vers le fournisseur autorisation point de terminaison avec les portées demandées.
L’utilisateur approuve l’écran de consentement ; le fournisseur redirige vers l’arrière avec un unique code d’autorisation à /v1/admin/connections/oauth/callback.
À l’intérieur du gestionnaire de rappel, AiHummer échange ce code côté serveur contre un jeton d’accès (et, lorsque le fournisseur le permet, un rafraîchir le jeton) au point de terminaison de jeton du fournisseur.
Le jeton est écrit dans le coffre et la connexion est marquée comme active.

L’échange de code contre un jeton se fait côté serveur à l’intérieur du rappel, donc le secret client et le jeton émis ne quittent jamais la passerelle.

[!NOTE] Ne confondez pas ce flux avec POST /v1/oauth/token: c’est à AiHummer posséder Point de terminaison des informations d’identification du client OAuth2 — comptes de service enregistrés via /v1/admin/apikeys/register-client échanger leur client_id/client_secret là pour une courte durée ah- jeton. Cela n’a rien à voir avec un tiers Connexions.

[!NOTE] Le flux d’autorisation par code implique toujours une étape de consentement via un vrai navigateur. A La connexion ne peut pas être créée sans interface à partir d’une seule clé API — l’utilisateur agissant doit approuver les autorisations une fois.

Où vit le jeton

Le jeton émis est stocké dans AiHummer. coffre-fort de credentials chiffrés, pas en configuration simple. Le coffre utilise le chiffrement par enveloppe (AES-256-GCM avec une clé de données par locataire sous une clé principale), et les secrets ne sont jamais copiés dans le contexte du modèle, les invites ou les journaux. Une Connexion révoquée ou expirée ne laisse tout simplement aucun secret utilisable derrière elle.

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

Résolu par l’utilisateur en fonction

La propriété définissante d’une Connexion est qu’elle est résolu par l’utilisateur en fonction. Lorsqu’un agent utilise un outil qui nécessite le fournisseur, le runtime recherche la Connexion appartenant à l’utilisateur pour le compte duquel le tour est exécuté, et utilise son jeton. Deux employés parlant au même agent agissent donc avec leurs propres autorisations et ne voient que ce que leur propre autorisation permet.

C’est ce qui rend Connections adapté aux intégrations personnelles et par utilisateur : l’accès de chaque personne est isolé, vérifiable et révoquable individuellement.

Intégrations disponibles

Grâce au flux OAuth2, un utilisateur peut connecter son propre compte à n’importe lequel des services d’expédition. Ces intégrations personnelles sont disponibles immédiatement :

Groupe	Services
Google	Gmail, Google Agenda, Contacts Google, Google Tâches, Google Drive, YouTube
Microsoft	Courrier Outlook, Calendrier Outlook, OneDrive, Microsoft To Do
Productivité	Todoist, Asana, Jira Cloud, ClickUp, GitLab, Linear, monday.com
Santé et mode de vie	Fitbit, Oura Ring, Strava, Spotify, Samsung SmartThings

Chacun se connecte avec le même flux de code d’autorisation : l’utilisateur complète l’écran de consentement du fournisseur, le jeton est scellé dans le coffre-fort, et il se résout pour cet utilisateur chaque fois qu’un outil accède au service.

Gestion des connexions dans l’interface d’administration

Depuis l’interface d’administration, un opérateur peut :

Voir quels fournisseurs chaque utilisateur a connectés et l’état de chaque jeton.
Démarrer une nouvelle connexion (lancer le processus de consentement pour un fournisseur choisi).
Révoquer une connexion, ce qui supprime l’entrée du coffre et désactive la résolution.

Les connexions sont soit personnel (appartient à un utilisateur spécifique, qui peut les déconnecter) ou partagé avec l’espace de travail (étiqueté “Espace de travail partagé” ; ils ne peuvent pas être déconnectés personnellement). Un fournisseur peut détenir plusieurs comptes: le bouton « + compte » demande une étiquette et enregistre une autre information d’identification du même fournisseur — par exemple plusieurs calendriers ou boîtes mail Google.

Parce que les informations d’identification sous-jacentes sont personnelles, une Connexion est le plus souvent l’outil approprié lorsqu’une action doit être attribuée à une personne spécifique et limitée par son autorisation, plutôt qu’à un compte général de l’espace de travail.

Où aller ensuite

Identifiants personnels vs partagés — le plein modèle de portée et quand choisir chacun.
Fournisseurs LLM BYOK — apportez vos propres clés de modèle par locataire.
Aperçu du marché et niveaux — où Les intégrations basées sur OAuth conviennent.