From 4c79bb0a5906343be3ad464fb709a3a116568f1d Mon Sep 17 00:00:00 2001 From: rishabhraj36 Date: Tue, 16 Jun 2026 11:49:02 +0530 Subject: [PATCH 1/2] feat: added support for agents --- README.md | 8 ++++++ docs/site/compared.mdx | 59 +++++++++++++++++++++++++++++++++++++++++- 2 files changed, 66 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 84064f31..628cb419 100644 --- a/README.md +++ b/README.md @@ -102,6 +102,14 @@ Authsome gives agents one command for a valid token, without scattering long-liv --- +## Comparing tools + +- [Authsome vs OneCLI vs Agent Vault](https://authsome.ai/docs/compared) + +This page covers architecture differences, OAuth nuances (including client-app ergonomics), and when each tool is a better fit. + +--- + ## Install Requires Python 3.13+. diff --git a/docs/site/compared.mdx b/docs/site/compared.mdx index 746addf9..9a716605 100644 --- a/docs/site/compared.mdx +++ b/docs/site/compared.mdx @@ -16,7 +16,7 @@ Authsome is a local credential broker for AI agents. The space it competes with | Built-in OAuth2 + API-key flows | Yes | No | No | Build it | | Headless agent runtime | Yes | Yes | Yes | Varies | | Local, no SaaS dependency | Yes | Yes | No | Yes | -| Built-in providers, zero config | 45 bundled | None | None | None | +| Built-in providers, zero config | Yes (see bundled providers list) | None | None | None | | Multi-account per provider | Yes | No (one env per key) | Sometimes | Build it | | Encrypted at rest | Yes (AES-256-GCM) | No (plaintext file) | Yes | Varies | | Secrets out of child env | Yes (proxy injection) | No | No | Build it | @@ -93,6 +93,63 @@ There are a handful of credential-management tools in adjacent spaces. Worth a q - **OAuth2 client libraries (`httpx-oauth`, `authlib`).** Building blocks, not a complete broker. They're what authsome uses internally. - **`onecli` / OneCLI.** Closest comparison: also an open-source credential vault for AI agents. Different design choices around hosting, dashboard, and the policy layer. +## Authsome vs other agent credential brokers + +For teams deciding between open-source agent credential brokers, these are the practical differences to evaluate first. + +| | Authsome | OneCLI | Agent Vault | +|---|---|---|---| +| Core model | Provider-centric credential broker for OAuth, API keys, and browser credentials | Team gateway for project/org-scoped secrets and app connections | Vault-scoped MITM broker with user/agent grants and proposal workflow | +| Runtime delivery | Proxy injects auth headers at request time | Gateway injects at request time (supports stub workflows too) | MITM injects at request time via vault service rules | +| OAuth token lifecycle support | Yes (PKCE, device code, DCR flows; refresh handling) | Yes (OAuth app connections + callback/token exchange + refresh paths) | Yes (OAuth credentials, connect/callback, token upload, refresh handling) | +| Default client-app ergonomics | Bundled provider definitions; some flows can start without manual app registration, others are BYOC | App definitions can use configured platform/default OAuth client apps, with BYOC app config as an override/path | OAuth works, provider URL presets exist, client credentials are typically user-provided (or token paste/import) | +| API-key workflows | Yes | Yes | Yes | +| Bundled provider / app registry | Yes (provider definitions) | Yes (app/integration registry with OAuth, API-key, and other connection methods) | No (service + credential model) | +| Non-HTTP config/file secret substitution | Not a primary feature | Not a primary feature | Not the core model; some placeholder file workflows exist in guides | +| Main deployment posture | Local-first CLI + daemon (self-hosting optional) | Dashboard/API + Rust gateway + Postgres | Single Go binary (API/UI + MITM), multi-user vault model | +| Team / multi-user | Principals, identity claims, per-principal vaults, admin/user roles, and multi-account provider connections | Org/project/team model with web UI, agents, policy rules, audit/request logs, and scoped secrets/app connections | Multi-user instance and vault model with users, agents, instance roles, vault roles, and proposal approvals | + +### OAuth nuance that is easy to miss + +A binary “OAuth: yes/no” row is usually misleading. A better split is: + +1. **OAuth protocol support**: can it do authorize/callback/token exchange/refresh? +2. **Client app ergonomics**: how are OAuth client apps supplied, resolved, or overridden? + +All three can support OAuth token lifecycles. Where they differ is the client-app and operator model: + +- Authsome emphasizes provider definitions and flow handling as first-class concepts. +- OneCLI emphasizes app connections, gateway policy context, and app credential resolution from project config or platform defaults. +- Agent Vault emphasizes vault-scoped credentials/services with optional OAuth connect and token import modes. + +### When to choose each + +#### Choose Authsome when + +- You want OAuth-heavy agent workflows with provider-centric login UX. +- You want a local-first CLI/daemon flow for developer machines and small self-hosted setups. +- You want one broker that handles API-key and OAuth flows under the same provider model. + +#### Choose OneCLI when + +- You want a dashboard-first, team-oriented deployment with org/project abstractions. +- You want a Rust gateway + policy layer around injected credentials. +- You already run Postgres and prefer web-admin-heavy operations. + +#### Choose Agent Vault when + +- You want a single-binary control plane + MITM runtime with explicit vault/user/agent roles. +- You want proposal-based access expansion and strong vault-level governance workflows. +- You want optional OAuth credential handling plus static/dynamic credential strategies in one vault model. + +### Caveats for fair comparisons + +- Feature names differ across tools (`provider`, `app`, `service`, `credential`) and are not one-to-one. +- Deployment shape matters as much as features (local-first vs multi-user service footprint). +- OAuth support does **not** always mean zero setup: client app requirements vary per integration and deployment policy. + +If you're evaluating for adoption, run a small pilot with one real OAuth provider and one API-key provider before deciding. + ## When authsome is the right tool You want all of: From 44b37bf6f0bd95ba2001220b6ca2733d7f6c439b Mon Sep 17 00:00:00 2001 From: rishabhraj36 Date: Tue, 16 Jun 2026 15:42:52 +0530 Subject: [PATCH 2/2] docs: refine credential broker comparison --- README.md | 8 -------- docs/site/compared.mdx | 39 +++++++++++++++++++-------------------- 2 files changed, 19 insertions(+), 28 deletions(-) diff --git a/README.md b/README.md index 628cb419..84064f31 100644 --- a/README.md +++ b/README.md @@ -102,14 +102,6 @@ Authsome gives agents one command for a valid token, without scattering long-liv --- -## Comparing tools - -- [Authsome vs OneCLI vs Agent Vault](https://authsome.ai/docs/compared) - -This page covers architecture differences, OAuth nuances (including client-app ergonomics), and when each tool is a better fit. - ---- - ## Install Requires Python 3.13+. diff --git a/docs/site/compared.mdx b/docs/site/compared.mdx index 9a716605..66bdfe4b 100644 --- a/docs/site/compared.mdx +++ b/docs/site/compared.mdx @@ -95,60 +95,59 @@ There are a handful of credential-management tools in adjacent spaces. Worth a q ## Authsome vs other agent credential brokers -For teams deciding between open-source agent credential brokers, these are the practical differences to evaluate first. +For teams deciding between open-source agent credential brokers, the useful comparison is less "who has OAuth?" and more "which operating model fits your agents, team, and deployment?" | | Authsome | OneCLI | Agent Vault | |---|---|---|---| -| Core model | Provider-centric credential broker for OAuth, API keys, and browser credentials | Team gateway for project/org-scoped secrets and app connections | Vault-scoped MITM broker with user/agent grants and proposal workflow | -| Runtime delivery | Proxy injects auth headers at request time | Gateway injects at request time (supports stub workflows too) | MITM injects at request time via vault service rules | -| OAuth token lifecycle support | Yes (PKCE, device code, DCR flows; refresh handling) | Yes (OAuth app connections + callback/token exchange + refresh paths) | Yes (OAuth credentials, connect/callback, token upload, refresh handling) | -| Default client-app ergonomics | Bundled provider definitions; some flows can start without manual app registration, others are BYOC | App definitions can use configured platform/default OAuth client apps, with BYOC app config as an override/path | OAuth works, provider URL presets exist, client credentials are typically user-provided (or token paste/import) | +| Core model | Provider-centric credential broker for OAuth, API keys, and browser credentials | Dashboard-backed gateway for project/org-scoped secrets and app connections | Vault-scoped credential proxy with user/agent grants and proposal workflow | +| Runtime delivery | Proxy resolves the matching provider and injects auth headers at request time | Gateway swaps placeholders and injects credentials into matching outbound requests | MITM proxy attaches credentials through vault service rules | +| OAuth token lifecycle support | Yes: PKCE, device code, DCR, callback/token exchange, and refresh handling | Yes: OAuth app connections, callback/token exchange, and refresh-aware credentials where supported by the app definition | Yes: OAuth credential type with connect, token paste/import, and refresh handling | +| Default client-app ergonomics | Bundled provider definitions; DCR-capable providers can avoid manual app setup, while other OAuth providers use your client app credentials | App registry with configurable OAuth app credentials and environment/default resolution paths | Provider URL presets help fill OAuth endpoints; operators typically supply client credentials or paste/import existing tokens | | API-key workflows | Yes | Yes | Yes | -| Bundled provider / app registry | Yes (provider definitions) | Yes (app/integration registry with OAuth, API-key, and other connection methods) | No (service + credential model) | -| Non-HTTP config/file secret substitution | Not a primary feature | Not a primary feature | Not the core model; some placeholder file workflows exist in guides | -| Main deployment posture | Local-first CLI + daemon (self-hosting optional) | Dashboard/API + Rust gateway + Postgres | Single Go binary (API/UI + MITM), multi-user vault model | +| Bundled provider / app registry | Yes: provider definitions | Yes: app/integration registry with OAuth, API-key, and import methods | Service + credential model rather than a fixed app registry | +| Beyond auth-header injection | Focuses on provider-routed auth injection and token lifecycle | Supports gateway injection plus credential stubs for some tool bootstrapping workflows | Supports service-scoped placeholders in paths, query strings, headers, bodies, and WebSocket frames | +| Main deployment posture | Local-first CLI + daemon, with server components available for shared setups | Web dashboard/API + Rust gateway + Postgres, commonly run through Docker/local mode | Single Go binary or container running API/UI + MITM proxy, often deployed as a separate broker host | | Team / multi-user | Principals, identity claims, per-principal vaults, admin/user roles, and multi-account provider connections | Org/project/team model with web UI, agents, policy rules, audit/request logs, and scoped secrets/app connections | Multi-user instance and vault model with users, agents, instance roles, vault roles, and proposal approvals | ### OAuth nuance that is easy to miss -A binary “OAuth: yes/no” row is usually misleading. A better split is: +A binary "OAuth: yes/no" row is usually misleading. A better split is: 1. **OAuth protocol support**: can it do authorize/callback/token exchange/refresh? 2. **Client app ergonomics**: how are OAuth client apps supplied, resolved, or overridden? -All three can support OAuth token lifecycles. Where they differ is the client-app and operator model: +All three can support OAuth token lifecycles. Where they differ is the client-app, provider, and operator model: -- Authsome emphasizes provider definitions and flow handling as first-class concepts. -- OneCLI emphasizes app connections, gateway policy context, and app credential resolution from project config or platform defaults. -- Agent Vault emphasizes vault-scoped credentials/services with optional OAuth connect and token import modes. +- Authsome emphasizes reusable provider definitions and flow handling as first-class concepts. +- OneCLI emphasizes app connections, gateway policy context, and app credential resolution from project config or defaults. +- Agent Vault emphasizes vault-scoped credentials/services, approval workflows, and flexible service rules. ### When to choose each #### Choose Authsome when -- You want OAuth-heavy agent workflows with provider-centric login UX. -- You want a local-first CLI/daemon flow for developer machines and small self-hosted setups. +- You want OAuth-heavy agent workflows with provider-centric login and token lifecycle handling. +- You want a local-first CLI/daemon flow for developer machines, with room to grow into shared setups. - You want one broker that handles API-key and OAuth flows under the same provider model. #### Choose OneCLI when - You want a dashboard-first, team-oriented deployment with org/project abstractions. -- You want a Rust gateway + policy layer around injected credentials. -- You already run Postgres and prefer web-admin-heavy operations. +- You want a Rust gateway with web-managed agents, app connections, policies, and request logs. +- You prefer operations centered around a web dashboard and Postgres-backed service. #### Choose Agent Vault when - You want a single-binary control plane + MITM runtime with explicit vault/user/agent roles. - You want proposal-based access expansion and strong vault-level governance workflows. -- You want optional OAuth credential handling plus static/dynamic credential strategies in one vault model. +- You want static, OAuth, external-store, and dynamic credential strategies in one vault model. ### Caveats for fair comparisons - Feature names differ across tools (`provider`, `app`, `service`, `credential`) and are not one-to-one. - Deployment shape matters as much as features (local-first vs multi-user service footprint). -- OAuth support does **not** always mean zero setup: client app requirements vary per integration and deployment policy. +- OAuth support does **not** always mean zero setup: client app requirements vary by provider, integration, and deployment policy. -If you're evaluating for adoption, run a small pilot with one real OAuth provider and one API-key provider before deciding. ## When authsome is the right tool