AiHummer Connections (per-user OAuth2)
Connections are how an individual user grants AiHummer access to a third-party service on their own behalf. Instead of a single shared service account, each person runs a standard OAuth2 authorization-code flow, the resulting token is sealed in the encrypted vault, and at turn time the runtime resolves that user’s token when a tool needs it.
This is the “personal” half of AiHummer’s credential model. For the broader picture — when to prefer a shared credential and how the fallback works — see Personal vs shared credentials.
What a Connection is
A Connection binds three things together: a provider (the OAuth2 app you are authorizing against), a user (the person who completed the consent screen), and a vault entry (where the issued token is stored). Once established, any tool that acts on behalf of that user can transparently use the token without it ever appearing in the model context, in logs or in the prompt.
Connections are managed from the admin UI. The list shows each user’s connected providers, their status and when they were last refreshed.
The authorization-code flow
A Connection is created with the canonical three-legged OAuth2 authorization-code grant:
- The user starts a connection for a provider from the admin UI.
- AiHummer redirects the browser to the provider’s authorization endpoint with the requested scopes.
- The user approves the consent screen; the provider redirects back with a one-time authorization code.
- AiHummer exchanges that code for an access token (and, when the provider supports it, a refresh token) at the provider’s token endpoint.
- The token is written to the vault and the Connection is marked active.
The platform’s own token endpoint is:
POST /v1/oauth/tokenIt performs the server-side code-for-token exchange so that the client secret and the issued token never leave the gateway.
[!NOTE] The authorization-code flow always involves a real browser consent step. A Connection cannot be created head-less from an API key alone — the acting user must approve the scopes once.
Where the token lives
The issued token is stored in AiHummer’s encrypted credential vault, not in plain configuration. The vault uses envelope encryption (AES-256-GCM with a per-tenant data key under a master key), and secrets are never copied into the model context, prompts or logs. A revoked or expired Connection simply leaves no usable secret behind.
consent ─▶ code ─▶ POST /v1/oauth/token ─▶ access/refresh token ─▶ vault (encrypted)Resolved by the acting user
The defining property of a Connection is that it is resolved by the acting user. When an agent runs a tool that needs the provider, the runtime looks up the Connection belonging to the user on whose behalf the turn is running, and uses their token. Two employees talking to the same agent therefore act with their own authorizations and see only what their own grant allows.
This is what makes Connections suitable for personal, per-user integrations: each person’s access is isolated, auditable and individually revocable.
Available integrations
Through the OAuth2 flow a user can connect their own account to any of the shipping services. These personal integrations are available out of the box:
| Group | Services |
|---|---|
| Gmail, Google Calendar, Google Contacts, Google Tasks, Google Drive, YouTube | |
| Microsoft | Outlook Mail, Outlook Calendar, OneDrive, Microsoft To Do |
| Productivity | Todoist, Asana, Jira Cloud, ClickUp, GitLab |
| Health & lifestyle | Fitbit, Oura Ring, Spotify, Samsung SmartThings |
Each one connects with the same authorization-code flow: the user completes the provider’s consent screen, the token is sealed in the vault, and it resolves for that user whenever a tool reaches the service.
Managing connections in the admin UI
From the admin UI an operator can:
- See which providers each user has connected and the health of each token.
- Start a new connection (kicking off the consent flow for a chosen provider).
- Revoke a connection, which removes the vault entry and disables resolution.
Because the underlying credentials are personal, a Connection is most often the right tool when an action must be attributed to, and constrained by, a specific human’s authorization rather than a workspace-wide account.
Where to next
- Personal vs shared credentials — the full scope model and when to choose each.
- BYOK LLM providers — bring your own model keys per tenant.
- Marketplace overview & tiers — where OAuth-backed integrations fit.