René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"feat: Google Service Account secret type (JWT → Bearer token injection)","articleBody":"## Summary\n\nAdd a `google_service_account` secret type that lets agents call Google APIs (Drive, Sheets, etc.) authenticated as a GCP service account — without the SA private key ever entering the agent's environment.\n\nThe gateway holds the SA JSON key in the vault, signs a short-lived JWT (RS256), exchanges it at `oauth2.googleapis.com/token`, caches the access token, and injects it as a Bearer header into matching requests. This is the same pattern the GitHub App integration already uses (private key → signed JWT → short-lived token → header injection).\n\n## Motivation / use case\n\nMulti-agent setups where different agents need access to *different* Google Drive data. Example: an HR agent and a Dev agent, each assigned (via selective secret mode) a different service account that is a member of only its department's shared drive. Isolation is enforced by Google-side permissions + per-agent secret grants — a compromised agent cannot reach the other department's data, and cannot exfiltrate the key because only the resolved short-lived token ever crosses the gateway.\n\nThe existing OAuth \"apps\" connectors cover human-account flows, and Vertex AI covers `cloud-platform` scope on aiplatform hosts, but there is currently no way to use a plain service account against general Google APIs.\n\n## Design decisions (feedback welcome)\n\n- **Secret, not App.** SA keys are bring-your-own credentials with a user-configurable host pattern, which matches the Secret abstraction\n  (host/path matching + injection). Apps are provider integrations with lifecycle management. Happy to discuss if you'd prefer this as an app  provider instead.\n- **Token resolution in the connect phase**, mirroring the existing OpenAI OAuth refresh (`connect.rs`), keeping `build_injections()` synchronous.\n- **JWT claims omit `sub`.** `sub` is only meaningful for domain-wide delegation; without DWD it can cause `invalid_grant`. (The Vertex AI path\n  keeps `sub` — unchanged.) Shared JWT-exchange logic could be factored out of `refresh_via_service_account()` with `scope`/`sub` parameterized.\n- **Default hostPattern `www.googleapis.com`** (not `*.googleapis.com`), to avoid matching the token endpoint and colliding with Vertex AI hosts. An\n  explicit guard also skips injection for `oauth2.googleapis.com` even if a user broadens the pattern.\n- **In-memory token cache** (~50 min TTL, 10 min safety margin), keyed by `secret_id + hash(secret value)` so key rotation invalidates immediately.\n  No DB write-back. Note: on the Cloud edition this cache is Redis, meaning short-lived access tokens would transit the shared cache — flagging for review.\n- **Scope hardcoded to `drive.readonly` for MVP**, surfaced in the UI.\n  Configurable scopes (via secret metadata) planned as a follow-up.\n- **Metadata stores only `client_email` / `project_id`** — never the private\n  key. Tests assert the key does not leak into metadata or error messages.\n\n## Status\n\nImplemented in my fork (yosukekmt/onecli), including validation/service layer, dialog UI with JSON key upload + parsed preview, gateway resolution with the cache behavior above, and unit tests (validation, service layer, and token-resolution cache hit/miss/expiry/rotation via an injected fetcher).\n\nI'd like to submit this as a PR for this.","author":{"url":"https://github.com/yosukekmt","@type":"Person","name":"yosukekmt"},"datePublished":"2026-07-07T02:57:42.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/414/onecli/issues/414"}