Skip to main content
← Back to list
01Issue
FeatureOpenSwamp CLI
AssigneesNone

Relationships

#1614 GC expired OAuth server tokens and control plane secrets

Opened by stack72 · 8/12/2026

Problem

Every swamp auth server-login against an OAuth-mode server mints a new oauth-<random> server token with a 30-day expiry (DEFAULT_DURATION_MS). Old tokens are never cleaned up, even after they expire. Over time this accumulates unbounded state across four locations:

  1. Definition YAML in .swamp/auto-definitions/swamp/server-token/<id>.yaml
  2. Token data record in the unified data repo (e.g. GCS)
  3. Token plaintext secret in the control plane vault (_token-secrets)
  4. OAuth access token in the control plane store (oauth-access-token-<name>)

A team of 10 people logging in once a day generates 300 stale token records per month, none of which are ever removed.

Proposed Solution

Add a periodic GC sweep to swamp serve that cleans up expired (and revoked) server tokens. The sweep should:

  1. Scan all swamp/server-token definitions
  2. For each token where state === "expired" or state === "revoked" (or expiresAt has passed), delete:
    • The token secret from the control plane vault (_token-secrets)
    • The OAuth access token from the control plane store (oauth-access-token-<name>)
    • The token data record from the unified data repo
    • The definition YAML from auto-definitions
  3. Run on a configurable interval (e.g. --token-gc-interval, default hourly)
  4. Run once at startup after token secret migration completes
  5. Log the count of cleaned-up tokens at info level

Considerations

  • Grace period — don't GC tokens immediately on expiry. A short grace period (e.g. 1 hour past expiresAt) avoids racing with a token that's about to be refreshed or a clock skew edge case.
  • Active sessions — an expired token may still have active WebSocket connections that authenticated before expiry. GC should not force-disconnect these; the session timeout handles that independently.
  • Revoked tokens — these can be GC'd immediately since revocation is a deliberate admin action.
  • swamp access token list — should continue to show recently expired/revoked tokens for auditability. Consider a --include-gc'd flag or a retention window for the list view.

Alternatives

  • CLI command (swamp access token gc) — manual cleanup, useful but doesn't solve the unbounded growth for unattended servers
  • TTL on the control plane store — if the datastore supports object TTL (e.g. GCS lifecycle rules), expired secrets could be auto-deleted at the storage layer, but this doesn't clean up definitions or data records
02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED

Open

8/12/2026, 12:07:24 AM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.