Skip to main content
← Back to list
01Issue
FeatureShippedSwamp ClubTeam
Assigneesstack72

Relationships

#960 Fine-grained scopes for swamp.club access tokens

Opened by evrardjp · 7/4/2026· Shipped 7/24/2026

Problem

swamp.club access tokens currently appear to have a broad account-level scope. This makes it hard to use tokens safely in automation/CI because a token intended only for extension publishing may also be able to perform unrelated sensitive actions.

Desired capability

When creating an access token, allow selecting fine-grained permissions/scopes. For example, I want to create a token that can publish extensions, but cannot:

  • change my user profile
  • yank/unyank/hide extensions
  • link or unlink accounts
  • perform other account-management actions

Proposed solution

Add scoped access tokens with explicit capabilities, such as:

  • extensions:publish
  • extensions:yank
  • extensions:unyank
  • extensions:hide
  • profile:write
  • accounts:link

The token creation UI/API/CLI should let users choose the minimal required permissions, and the registry/API should enforce those scopes on every authenticated action.

Why this matters

This would follow least-privilege principles and make it safer to store swamp.club tokens in CI/CD systems, especially for publishing extensions, without granting broad account control.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 5 MOREFINDINGS+ 1 MOREIMPLEMENTATION+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

7/24/2026, 12:35:35 AM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack727/14/2026, 6:19:19 PM
Editable. Press Enter to edit.

stack72 commented 7/24/2026, 12:34:40 AM

Shipped: fine-grained scopes for collective API tokens

This has been implemented across 8 PRs spanning both the swamp-club web app and the swamp CLI.

What was built

Scope system:

  • 22 scopes across 10 resource categories: extensions (push, promote, read, wildcard), lab, profile, collective, billing, feed, notifications, oauth, serve, datastore, and vault
  • Wildcard expansion — extensions:* grants all fine-grained extension scopes
  • Legacy token detection — existing tokens default to extensions:* and show a "LEGACY — ROTATE" warning badge in the UI

Enforcement:

  • Server-side requireScope() guard on all collective-token-accessible routes (push, confirm, promote, search)
  • Clear 403 messages naming the missing scope
  • Infrastructure scopes (serve:*, datastore:*, vault:*) enforced at CLI command level for team features

Token creation:

  • Web UI scope selector at /o/[slug]/settings with grouped checkboxes (Extensions + Infrastructure)
  • API accepts optional scopes parameter on POST /api/v1/collectives/[slug]/api-tokens
  • CLI command: swamp auth token create --collective <slug> --scopes extensions:push,serve:*

CLI support:

  • Full collective token support — swamp auth whoami shows scopes, swamp extension push works with collective tokens
  • Scope-aware error messages on 403s

Introspection:

  • GET /api/whoami returns scopes for collective tokens
  • swamp auth whoami displays granted scopes

What this enables

CI pipelines can now create a token with only extensions:push and nothing else. That token can publish extensions but cannot promote, search private extensions, or perform any infrastructure operations. This is the least-privilege model requested in the issue.

Infrastructure tokens (serve:*, datastore:*, vault:*) authenticate team services with swamp-club.com, gating swamp serve, remote datastore setup, and non-local vault creation behind collective membership.

Remaining

  • #1374 — one explanation doc page still argues against fine-grained scopes and needs rewriting
  • #1375 — end-to-end UAT checklist
  • Personal API key scopes are a separate future track (different implementation path via BetterAuth)

stack72 commented 7/24/2026, 12:36:40 AM

Thanks @evrardjp for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.