`e2a login` accumulates API keys per invocation; align with per-device behavior

[jiashuoz]

Summary

Every successful e2a login mints a new API key via store.CreateAPIKey(ctx, userID, "CLI login") regardless of whether the user already has prior keys. There's no dedup, no replacement, no expiration. After running login a few times, a user has multiple keys all literally named "CLI login".

Sample outcome after three e2a login runs from different machines (or the same machine after a config wipe):

e2a_aaa…  CLI login   (active)
e2a_bbb…  CLI login   (active)
e2a_ccc…  CLI login   (active)

Concrete pain

• Indistinguishable in the dashboard / future keys list. When a user wants to revoke "the key on the laptop I lost," they can't tell which row that is.
• Stale keys remain valid forever. No expires_at field in the schema; revocation requires explicit user action. A key from a stolen device or a past colleague's machine is live until manually revoked.
• Sprawl over time. Power users who re-clone configs or work across machines accumulate dozens of identically-named entries.

Surfaced during fresh-user e2e testing for the launch.

How comparable tools handle it

gcloud uses OAuth refresh tokens, not API keys. gcloud auth login <account> updates the entry in place — re-login doesn't accumulate credentials. Different model end-to-end, but the user-facing behavior is "one credential per account, replaced on re-auth."

gh (GitHub CLI) issues an access token via OAuth. Re-running gh auth login invalidates the prior token on the same scope; tokens are auto-named gh-cli for <hostname>. User-facing behavior is "one credential per device, with a meaningful name."

stripe CLI issues a device-scoped key, named after the host.

Proposed paths

Path A — Revoke-on-login (smallest change)

On e2a login:

1. Read existing config; if api_key is set, capture its prefix (or call a whoami endpoint to get its ID)
2. After OAuth completes and the new key is minted, revoke the old one
3. Save the new key to ~/.e2a/config.json

Result: at most one CLI key per machine that's been using e2a login. Server-side change minimal — uses the existing key-revocation endpoint.

Path B — Hostname-aware names + per-name dedup (recommended)

On e2a login:

1. CLI passes os.hostname() as the key name hint: "CLI login on joshzhang-MBP-2026" instead of the generic "CLI login"
2. Server checks for existing keys with the same (user_id, name) pair and revokes them before minting the new one
3. Each machine ends up with exactly one CLI key, distinctively named in the dashboard

Result: dashboard's "API keys" view becomes meaningful. User can identify and revoke a specific machine without guessing.

Path C — OAuth refresh-token model

Drop the long-lived API key for the CLI entirely. Issue an OAuth-style access token (~1hr) plus a refresh token. SDKs and CLI handle 401 → refresh → retry.

Better security model. Significant refactor: every SDK auth flow changes, all API consumers need refresh logic, the API-key-in-Authorization-header pattern becomes a parallel auth path.

My take

Path B. It's the right user-mental-model fit ("one device = one key, with a name I recognize") and it's well under a day of work:

• CLI: pass os.hostname() in the key-creation request
• API: when (user_id, name) collides on create, auto-revoke prior key
• No SDK changes, no breaking auth changes for existing users

Path A is simpler but leaves the dashboard cluttered with identically-named keys. Path C is the architecturally right answer but costs more than its payback for an OSS launch.

Belt-and-suspenders worth considering on top of B: add a last_used_at column (already exists per migrations/001_init.sql) and run a periodic worker that revokes keys with last_used_at < now() - 90 days. Bounded blast radius for forgotten keys without bothering active users.

Priority

Not blocking launch. Should land before the project sees enough adoption that users start having multiple devices and forget which key is which — meaning soon-after-launch, not immediately.

[jiashuoz]

🔍 Issue audit (automated triage, 2026-06-26)

• Stale? No — the described behavior is still present on main. internal/auth/auth.go:247 unconditionally calls ua.store.CreateAPIKey(r.Context(), user.ID, "CLI login", nil) with a hardcoded name and nil expiry on every successful OAuth callback. No dedup, no revoke-of-prior, no hostname in the name. The cliLoginHandoff struct carries no device hint, and CreateScopedAPIKey does a raw INSERT with no upsert/conflict resolution. The CLI's login.ts also passes no device_name parameter. Every re-login mints a new, identically-named, never-expiring key.

• Severity — medium. No data loss and no immediate unauthorized access; keys are revocable. But every re-login silently accumulates "CLI login" rows that are indistinguishable in the dashboard, and any key on a lost/wiped machine stays live until manually found and revoked.

• Correctness bug? No — the system produces the intended output (a working key) but the design is poor UX and a mild security-hygiene gap. Enhancement/hardening, not a data-corrupting defect.

• Root cause — writeCLIHandoffPage in internal/auth/auth.go:246-258: no step reads an existing CLI key for the user, no revoke before mint, and the name is the static string "CLI login" rather than something device-identifying.

• Best fix — Path B from the issue is right. Concrete steps:

  1. CLI (cli/src/commands/login.ts, buildBrowserLoginURL): append device_name=<os.hostname()> to the login URL query string.
  2. Server (HandleLogin → OAuth state or handleCLICallback): plumb device_name through cliLoginHandoff; read it in writeCLIHandoffPage; use it as the key name ("CLI login on joshzhang-MBP-2026").
  3. Add store.RevokeAPIKeysByName(ctx, userID, name string) error — a soft-delete (UPDATE api_keys SET revoked_at = now() WHERE user_id=$1 AND name=$2 AND revoked_at IS NULL) — and call it just before CreateAPIKey in writeCLIHandoffPage. No migration needed; revoked_at and the idx_api_keys_user index already exist (migrations/001_init.sql).
  4. Sanitize/truncate device_name server-side (printable ASCII, ≤64 chars) before using it as the key name to prevent injection into the dashboard label.

  Path A (revoke by prefix from saved config) is a valid fallback but requires the CLI to already have a valid key to look up the old key ID, which is circular on first login after a config wipe. Path B avoids that dependency entirely.

• Worth fixing? Fix later — not GA-blocking (the issue says so, and it is correct), but should land before meaningful adoption. Small, self-contained change with no breaking surface; estimated under a day of work. The last_used_at column already exists so a "revoke keys idle >90 days" cron job (mentioned in the issue as belt-and-suspenders) is a natural follow-on, not a prerequisite.