What does this skill do, and when should you use it?
Authsome is a credential gateway that sits between AI agents and the external services they call. You authenticate once via OAuth2 (browser PKCE, device code, or a browser bridge) or API keys; Authsome stores credentials encrypted and injects them into outbound HTTP requests through a proxy. Agents run commands prefixed with `authsome run --`, and the gateway adds the right auth headers at request time without exposing secrets in the child process environment. It supports many bundled providers (Gmail, GitHub, Google Calendar/Drive, Stripe, etc.), automatic token refresh, multiple accounts per provider, and self-hosting via Docker. Licensed MIT, Python 3.13+.
Provides a CLI (authsome) that: stores OAuth2 tokens and API keys in an encrypted local store after a one-time authsome login <provider> browser flow; transparently proxies outbound HTTPS traffic from commands wrapped in authsome run --, injecting credentials as HTTP headers matched by provider api_url; refreshes tokens before expiry and handles 401 (re-login) and 403 (re-login with --scopes) failures; manages providers and connections via authsome provider list/remove/revoke and authsome connections; and can run as a persistent daemon (Docker with Postgres) for self-hosting.
- A developer running Claude Code or Codex who wants the agent to read Gmail, check a Stripe balance, or call the GitHub API without pasting tokens into the conversation or environment variables.
- A team running agents in CI, cron jobs, SSH sessions, or background workers that need API access with no human and no browser in the loop after initial setup.
- A security-conscious engineer who wants one encrypted store for all agent credentials, with key rotation and per-agent activity visibility instead of hardcoded env tokens scattered across projects.
- An operator self-hosting infrastructure who wants a central credential daemon (Docker + Postgres) with TLS and backup control.
- A developer whose agent hits a 403 due to missing OAuth scopes and needs to re-login with `--scopes` on the existing provider rather than re-registering it.
How do you install this skill?
- Static review only; nothing was executed; all scores are low-confidence.
- The skill routes ALL outbound HTTPS traffic through a transparent proxy; confirm you accept this network-layer change and its rollback path before installing.
- Dependencies include posthog telemetry and browser-cookie3 (reads browser cookies); privacy-sensitive users should audit upstream code first.
- Core function depends on a local/remote daemon and overseas OAuth providers; mainland-China reachability is undocumented and may render it unusable.
- A real failure documented in feedback.md (NO_PROXY silently bypassing the proxy) shows the 'transparent proxy' claim can fail silently in some environments.
- Skill version 0.2.0 vs package version 0.7.2 mismatch with no changelog makes upgrade behavior unpredictable.
- Shell / CLI
- Network access
- Local filesystem
Python 3.13+uv (or pipx)
Requires Python 3.13+. Install the CLI: uv tool install authsome (fallback: pipx install authsome, or uvx authsome@latest <command> for one-off/sandboxed use). Run first-time setup: authsome onboard (optionally with --base-url https://... for a remote daemon). Add the skill to your agent: npx skills add agentrhq/authsome. Optional self-hosting: run the Docker Compose stack with AUTHSOME_POSTGRES_PASSWORD, AUTHSOME_MASTER_KEY, and AUTHSOME_UI_SESSION_KEY set, then check http://localhost:7998/health.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/agentrhq/authsome.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/authsome" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Log in once per provider: authsome login github (the browser opens on the user's machine; the user completes OAuth without sharing credentials with the agent). Verify with authsome provider list. Then prefix any outbound call with the gateway: e.g. authsome run -- curl -s "https://api.github.com/user/repos?per_page=10" or authsome run -- python my_agent_script.py. Standard HTTP clients (curl, git, requests, axios, Go net/http) honor HTTPS_PROXY automatically, so no auth headers are needed. On 401, revoke and re-login (authsome provider revoke <provider> then authsome login <provider>); on 403, re-login with --scopes. Check authsome --help and subcommand help for exact flags.
What are this skill's strengths and limitations?
- Agents never see credential values — auth is handled outside the agent process, eliminating exfiltration risk and secrets in environment variables.
- Automatic token refresh and built-in OAuth2/API-key providers, so no per-project auth plumbing.
- Headless after setup: browser is only needed at login time, suitable for CI, cron, and background workers.
- Multi-account per provider, provider/connection management commands, and clear failure-mode handling (401 vs 403 decision tree).
- Open source (MIT), self-hostable via Docker, and ships integrations for Claude Code, Codex, Cursor, OpenCode, LangChain, LlamaIndex, and OpenAI/Anthropic SDKs.
- Requires Python 3.13+, a relatively new floor.
- Initial setup requires a browser and human interaction — not fully zero-touch.
- Running commands through the proxy means all outbound traffic flows through the gateway/daemon, an extra moving part to trust and operate.
- Per-provider setup beyond bundled providers requires following references/adding-provider.md; the SKILL.md does not document that process inline.
- The source does not document Windows-specific behavior or provide benchmark/security-audit evidence; no per-request performance figures are given.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Authsome this page | 46 · Use with care | ★ 98 | 3mo ago | MIT |
| Security Hardening Engineering Skill | 52 · Use with care | ★ 107k | 12d ago | MIT |
| Varlock Secrets Guard Skill | 51 · Use with care | ★ 33 | 7mo ago | MIT |
| Google Cloud Authentication Guide ✓ Google · Official | 58 · Recommended | ★ 21k | 11d ago | Apache-2.0 |
| Postiz Agent Skill | 52 · Use with care | ★ 517 | 11d ago | NOASSERTION |
The README itself compares Authsome against hardcoded environment tokens and DIY auth (which require you to build token refresh, OAuth flows, and secret isolation yourself); it also contrasts with browser-manual workflows. Unlike env tokens, Authsome refreshes tokens automatically, supports multiple accounts per provider, and keeps credentials out of the agent process.
How did FollowSkills review this skill?
Evidence shows credentials are held by the gateway and injected via proxy; the skill forbids agents from touching or printing secrets, respects 403 policy blocks, and asks users to confirm OAuth endpoints. Deducted for: a transparent MITM proxy covering all outbound HTTPS (broad permission surface), undisclosed credential-storage/encryption and rollback boundaries, incomplete privacy disclosure around posthog telemetry and browser-cookie3 dependencies, and unverified publisher.
Evidence shows a self-consistent SKILL.md with login flow, 401/403 decision trees, install fallbacks, and help guidance; evals. defines 7 scenarios. Deducted for: no execution evidence, no committed tests covering the skill's key paths, and feedback.md documenting a real NO_PROXY-bypass failure (~8 failed attempts), showing the happy-path claim diverges from actual behavior and debugging cost was shifted to users.
Evidence shows clear target scenarios (Gmail/GitHub/Stripe access) and trigger description, with evals covering triggering and connection states. Deducted for: core function depends on a local/remote daemon plus overseas OAuth providers with no mainland-China reachability note; no declared non-fit boundaries; no Chinese-language consideration.
Evidence shows explicit MIT license, versioning (skill 0.2.0), layered references docs, feedback path, issue templates, and CI workflows. Deducted for: no changelog; skill version (0.2.0) diverges from package version (0.7.2) without explanation; key registration guide depends on an external raw.githubusercontent URL; maintenance ownership partly rests on an unverified publisher.
Evidence shows a clear value claim (credentials never enter the agent, no per-project auth plumbing) and plausible output paths in evals. Deducted for: static review cannot verify outputs are directly usable; the documented failure case suggests real usage may still need substantial debugging; marginal benefit over alternatives like an already-authenticated gh CLI is limited (eval 4 itself concedes this).
Evidence shows an auditable eval framework (evals. + report generator) and README badges for PyPI/CI/codecov. Deducted for: no committed eval results or third-party execution evidence in the repo; badges are claims, not static evidence; core security claims (credential invisibility, proxy injection) are not independently reproducible from files.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →