TapAuth

v1.0.3

OAuth token provider for OpenClaw agents — Google Calendar, Gmail, GitHub, Slack, Linear, Notion, Vercel, Sentry, Asana, Discord, or Apify. Integrates with O...

0· 634·2 current·2 all-time
byJonah Schwartz@schwartzdev
Security Scan
Capability signals
CryptoRequires OAuth tokenRequires sensitive credentials
These labels describe what authority the skill may exercise. They are separate from suspicious or malicious moderation verdicts.
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
Purpose & Capability
The skill name/description (OAuth token provider for many services) matches the files and runtime instructions. It requires curl and bash (documented) and includes a script that calls tapauth.ai to create grants and retrieve tokens. There are no unrelated env vars, binaries, or external downloads requested.
Instruction Scope
SKILL.md explicitly confines the agent to creating grants and configuring OpenClaw's exec secrets provider rather than directly capturing tokens. It instructs editing ~/.openclaw/openclaw.json and running openclaw secrets reload so the gateway runs the script with --token. This is expected for an exec-provider integration, but it does require granting the gateway the ability to run the bundled script and to pass TAPAUTH_HOME/HOME into the provider environment.
Install Mechanism
No install spec or remote downloads; the skill is instruction-first with local bash scripts included. No extract-from-URL or package registry installs are present. Risk from install mechanism is low.
Credentials
The skill declares no required env vars but the runtime requires setting TAPAUTH_HOME (or relying on default) and passing HOME into the exec provider; this is reasonable. The script caches grant credentials (TAPAUTH_GRANT_ID and TAPAUTH_GRANT_SECRET) to TAPAUTH_HOME with 600 permissions — bearer tokens are not written to disk per the code. Be aware the grant secret is a credential stored locally; SKILL.md's ‘no API key needed’ statement is accurate (the grant is created automatically), but it is still a secret persisted on disk.
Persistence & Privilege
always is false and model invocation is not disabled. The skill instructs adding an exec provider to openclaw.json so the gateway will run the included script at startup/reload to resolve tokens — this is normal for a secrets exec provider. The skill does not request permanent platform-wide privileges beyond that standard integration.
Assessment
TapAuth appears to do what it claims: create browser approval URLs, cache grant credentials locally, and let OpenClaw run the bundled script to fetch tokens into an in-memory secrets snapshot. Before installing, verify you trust the tapauth.ai service (the script contacts https://tapauth.ai by default) and are comfortable with the gateway running the included script as an exec secret provider. Note that the script saves grant credentials (grant ID and grant secret) to TAPAUTH_HOME with restrictive permissions — those are sensitive and required for token retrieval. Do not set TAPAUTH_BASE_URL to an untrusted host (it can redirect the script to another server). Finally, follow the SKILL.md rules: don't invoke tapauth.sh --token directly in shell substitutions or curl commands; instead configure the exec provider so tokens are resolved by OpenClaw.

Like a lobster shell, security has layers — review code before you run it.

latestvk97e1qbk3w2ywbtdxwjbt6tf1d84z2m8
634downloads
0stars
13versions
Updated 2d ago
v1.0.3
MIT-0

TapAuth — OAuth Tokens via OpenClaw Secrets Manager

TapAuth provides OAuth tokens through OpenClaw's exec secrets provider. Tokens are resolved at gateway startup and held in memory — they never appear in shell commands or config files as plaintext.

You must NEVER use tapauth.sh --token directly in shell commands, curl calls, or $(...) substitutions. Tokens are always resolved through the secrets manager. Your job as an agent is to configure the secrets provider, not to fetch tokens yourself.

When a user asks you to do something that needs an OAuth token

Follow these steps in order. Do not skip to step 3. Do not run --token yourself.

1. Create a grant and show the approval URL

Run the script without --token to create a grant. Set TAPAUTH_HOME so the grant cache is stored in a stable location that the exec provider can also find:

TAPAUTH_HOME=/home/node/.tapauth /home/node/.openclaw/skills/tapauth/scripts/tapauth.sh <provider> <scopes>

Example for Google Calendar:

TAPAUTH_HOME=/home/node/.tapauth /home/node/.openclaw/skills/tapauth/scripts/tapauth.sh google calendar.readonly

Output:

Approve access: https://tapauth.ai/approve/abc123

Show this URL to the user. Once they approve, run with --token to get the bearer token.

Show the approval URL to the user and ask them to approve. Wait for them to confirm before proceeding. That final line is the script's generic output. In OpenClaw, do not run --token yourself — proceed to step 2 and let the secrets manager invoke it.

2. Configure the exec secrets provider in openclaw.json

After the user confirms they approved, edit ~/.openclaw/openclaw.json to add an exec provider under secrets.providers:

{
  "secrets": {
    "providers": {
      "tapauth_google_calendar": {
        "source": "exec",
        "command": "/home/node/.openclaw/skills/tapauth/scripts/tapauth.sh",
        "args": ["--token", "google", "calendar.readonly"],
        "passEnv": ["HOME"],
        "env": {"TAPAUTH_HOME": "/home/node/.tapauth"},
        "jsonOnly": false
      }
    }
  }
}

Key fields:

  • command: Absolute path to scripts/tapauth.sh in this skill directory
  • args: ["--token", "<provider>", "<scopes>"] — must match the grant you created in step 1
  • jsonOnly: false: The script outputs a raw token string, not JSON
  • passEnv: Must include HOME
  • env.TAPAUTH_HOME: Must be /home/node/.tapauth — the same path used when creating the grant in step 1

Use the naming convention tapauth_<provider> or tapauth_<provider>_<scope> for the provider key.

3. Reload secrets and confirm

After editing openclaw.json, run:

openclaw secrets reload

This tells the gateway to re-resolve all secret providers. The exec provider runs tapauth.sh --token in the background and stores the result in the in-memory secrets snapshot.

Tell the user the setup is complete. The token is now resolved and will be available at every gateway startup. If the user repeats their request in a new session, the token will already be available.

If you need to verify immediately, run openclaw secrets reload and then retry the user's request through the normal OpenClaw secret path. Do not invoke tapauth.sh --token directly.

Rules

  • NEVER run tapauth.sh --token directly. Do not use it in $(...), do not capture its output, do not pipe it to curl. The secrets manager runs it for you.
  • NEVER skip the approval step. Always create the grant first (step 1), get user approval, then configure the provider (step 2).
  • No API key or credentials needed. TapAuth is zero-config. Do not look for API keys, client secrets, or environment variables.
  • Always use absolute paths for the command field in the exec provider config.

Quick Reference — Provider + Scopes

ProviderArgs for exec providerScopes Reference
Google Calendar["--token", "google", "calendar.readonly"]references/google.md
Google Drive["--token", "google", "drive.readonly"]references/google.md
Google Sheets["--token", "google", "spreadsheets.readonly"]references/google.md
Gmail["--token", "google", "gmail.send"]references/gmail.md
GitHub["--token", "github", "repo"]references/github.md
Vercel["--token", "vercel", "deployment"]references/vercel.md
Notion["--token", "notion", "read_content"]references/notion.md
Slack["--token", "slack", "users:read"]references/slack.md
Asana["--token", "asana", "tasks:read"]references/asana.md
Linear["--token", "linear", "read"]references/linear.md
Sentry["--token", "sentry", "project:read"]references/sentry.md
Discord["--token", "discord", "identify"]references/discord.md
Apify["--token", "apify", "full_api_access"]references/apify.md

Multiple scopes: comma-separate in a single string, e.g. ["--token", "google", "calendar.readonly,drive.readonly"].

Token Lifecycle

  • Resolution: Fresh tokens fetched at each gateway startup and openclaw secrets reload.
  • Caching: tapauth.sh caches tokens locally with expiry. Subsequent calls return instantly if valid.
  • Refresh: Expired tokens are refreshed automatically from the TapAuth API. No user interaction needed.
  • Re-approval: If a grant is revoked, delete ~/.tapauth/<provider>-<scopes>.env and re-run scripts/tapauth.sh to create a new grant.

Troubleshooting

SymptomCauseFix
token refresh failedGrant revoked or expiredDelete ~/.tapauth/<provider>-<scopes>.env, re-run scripts/tapauth.sh
Token works locally but not in OpenClawpassEnv missing HOMEAdd HOME to passEnv array
command must be absolute pathRelative path in commandResolve scripts/tapauth.sh to its absolute path
Symlink errorSkill installed via symlinkAdd allowSymlinkCommand: true and trustedDirs to provider config
tapauth: timed outGrant not pre-approvedRun scripts/tapauth.sh <provider> <scopes> without --token first

Comments

Loading comments...