AiHummer
Español
Iniciar sesiónCuenta
v1.1.x
{ }Swagger

Conexiones (OAuth2 por usuario)

v1.1.x · actualizada 2026-07-05

Conexiones son cómo un usuario individual otorga a AiHummer acceso a un servicio de terceros en su propio nombre. En lugar de una cuenta de servicio compartida, cada persona ejecuta un estándar flujo de código de autorización OAuth2, el token resultante se sella en la bóveda encriptada, y en el momento de ejecución, el tiempo de ejecución resuelve el token de ese usuario cuando una herramienta lo necesita.

Esta es la parte “personal” del modelo de credenciales de AiHummer. Para la imagen más amplia —cuándo preferir una credencial compartida y cómo funciona la alternativa— véase Credenciales personales vs compartidas.

Qué es una conexión

Una conexión une tres cosas: una proveedora (la aplicación OAuth2 contra la que estás autorizando), una usuaria (la persona que completó la pantalla de consentimiento), y un entrada de la bóveda (donde se almacena el token emitido). Una vez establecido, cualquier herramienta que actúe en nombre de ese usuario puede usar el token de manera transparente sin que aparezca nunca en el contexto del modelo, en los registros o en el aviso.

Las conexiones se gestionan desde la interfaz de administración. La lista muestra los proveedores conectados de cada usuario, su estado y cuándo se actualizaron por última vez.

El flujo de código de autorización

Se crea una conexión con la concesión de código de autorización OAuth2 de tres patas canónica:

  1. El usuario inicia una conexión para un proveedor desde la interfaz de administración — un POST/GET /v1/admin/connections/oauth/start solicitud.
  2. AiHummer redirige el navegador al proveedor autorización punto final con los alcances solicitados.
  3. El usuario aprueba la pantalla de consentimiento; el proveedor redirige de vuelta con un único código de autorización a /v1/admin/connections/oauth/callback.
  4. Dentro del manejador de devolución de llamada, AiHummer intercambia ese código del lado del servidor por un token de acceso (y, cuando el proveedor lo soporte, un token de actualización) en el endpoint de tokens del proveedor.
  5. El token se escribe en la bóveda y la Conexión se marca como activa.

El intercambio de código por token ocurre del lado del servidor dentro del callback, por lo que el secreto del cliente y el token emitido nunca salen de la puerta de enlace.

[!NOTE] No confundas este flujo con POST /v1/oauth/token: eso es de AiHummer propio Punto de enlace de credenciales de cliente OAuth2 — cuentas de servicio registradas a través de /v1/admin/apikeys/register-client intercambiar su client_id/client_secret allí por poco tiempo ah- token. No tiene nada que ver con terceros Conexiones.

[!NOTE] El flujo de código de autorización siempre implica un paso de consentimiento en un navegador real. A No se puede crear una conexión sin interfaz a partir de una clave de API solamente — el usuario que actúa debe aprobar los permisos una vez.

Dónde vive el token

El token emitido se almacena en AiHummer’s bóveda de credenciales encriptada, no en configuración simple. La bóveda utiliza cifrado de sobre (AES-256-GCM con una clave de datos por inquilino bajo una clave maestra), y los secretos nunca se copian en el contexto del modelo, solicitudes o registros. Una Conexión revocada o expirada simplemente no deja ningún secreto utilizable.

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

Resuelto por el usuario que actúa

La propiedad definitoria de una Conexión es que es resuelto por el usuario que actúa. Cuando un agente ejecuta una herramienta que necesita el proveedor, el entorno de ejecución busca la Conexión perteneciente al usuario en cuyo nombre se está realizando la acción, y utiliza su token. Por lo tanto, dos empleados que hablan con el mismo agente actúan con sus propias autorizaciones y solo ven lo que su propia concesión permite.

Esto es lo que hace que Connections sea adecuado para integraciones personales y por usuario: el acceso de cada persona está aislado, es auditable y puede revocarse individualmente.

Integraciones disponibles

A través del flujo OAuth2, un usuario puede conectar su propia cuenta con cualquiera de los servicios de envío. Estas integraciones personales están disponibles de manera inmediata:

Grupo Servicios
Google Gmail, Google Calendar, Contactos de Google, Tareas de Google, Google Drive, YouTube
Microsoft Correo de Outlook, Calendario de Outlook, OneDrive, Microsoft To Do
Productividad Todoist, Asana, Jira Cloud, ClickUp, GitLab, Linear, monday.com
Salud y estilo de vida Fitbit, Oura Ring, Strava, Spotify, Samsung SmartThings

Cada uno se conecta con el mismo flujo de código de autorización: el usuario completa la pantalla de consentimiento del proveedor, el token se guarda en la bóveda y se resuelve para ese usuario cada vez que una herramienta accede al servicio.

Gestionando conexiones en la interfaz de administración

Desde la interfaz de administración, un operador puede:

  • Vea qué proveedores tiene conectados cada usuario y el estado de cada token.
  • Inicie una nueva conexión (iniciando el flujo de consentimiento para un proveedor elegido).
  • Revocar una conexión, lo que elimina la entrada de la bóveda y desactiva la resolución.

Las conexiones son o personal (propiedad de un usuario específico, que puede desconectarlos) o compartido con el espacio de trabajo (etiquetado “Espacio de trabajo compartido”; no se pueden desconectar personalmente). Un proveedor puede mantener múltiples cuentas: el botón «+ cuenta» solicita una etiqueta y almacena otra credencial del mismo proveedor, por ejemplo, varios calendarios o buzones de Google.

Debido a que las credenciales subyacentes son personales, una Conexión es, en la mayoría de los casos, la herramienta adecuada cuando una acción debe ser atribuida y limitada por la autorización de un humano específico en lugar de una cuenta a nivel de espacio de trabajo.

¿A dónde vamos ahora?