← Back to list
01Issue
FeatureClosedSwamp CLI
AssigneesNone
Relationships
▾ parent of #667▾ parent of #668▾ parent of #670▾ parent of #672▾ parent of #675▾ parent of #678▾ parent of #682▾ parent of #685▾ parent of #688▾ parent of #689▾ parent of #683▾ parent of #690▾ parent of #680▾ parent of #674▾ parent of #673▾ parent of #694▾ parent of #703▾ parent of #704▾ parent of #702▾ parent of #710▾ parent of #1016▾ parent of #1015#662 Design: serve authentication & authorization (TLS, OAuth, access control)
Opened by adam · 6/16/2026
Design proposal (no implementation yet) for extending swamp serve beyond its single-host trust model into a network-exposable server with a coherent authentication and authorization posture. Written up as design/serve-auth.md, building on the existing orchestrator/worker remote-execution machinery.
Branch / PR
- Draft PR: https://github.com/swamp-club/swamp/pull/1587 (marked draft +
holdlabel) - Branch:
design-serve-auth - Doc:
design/serve-auth.md
What it proposes
- TLS — static certs and Let's Encrypt ACME (HTTP-01). Binding off-loopback without TLS is a hard startup refusal.
- Authentication — swamp serve as a generic OAuth 2.0 client; swamp-club.com as the default provider (better-auth's OAuth module + device authorization grant). Identity is established via a userinfo exchange rather than offline ID-token validation, sidestepping the JWT-validation footgun class; the one correctness item is verifying the token was issued for swamp's own client. SAML is brokered, never in-codebase. The server mints its own revocable tokens; the provider is consulted only at login.
- Admission policy — restrict login to particular collectives and/or whitelisted users (matched on stable subject).
- Mandatory configured admin — any enforcing mode requires at least one configured admin principal (granted admin on access:*), materialized at boot from config as the fail-safe root of who may change the rules. Off-loopback with auth disabled is also a hard refusal.
- Authorization — a new
domain/access/bounded context: grants and groups persisted as built-in models, deny-by-default with deny-wins precedence, IdP-asserted groups as first-class grant subjects. - CEL grant conditions — uniform with swamp's existing CEL surfaces, evaluated in a permanently sealed, deterministically cost-bounded environment.
- Rule packs — a tier-1 policy extension point shipping grants-as-data; context enrichers and external deciders scoped as later/non-goals.
Open questions
- Whether swamp-club will expose a public OAuth 2.0 authorization server with the device grant + collectives on userinfo (lynchpin; lives in the swamp-club repo).
- Default server-token lifetime vs. revocation latency for IdP-group membership.
- Break-glass locally-minted tokens under OAuth mode.
- Which deterministic predicate libraries the sealed CEL baseline launches with.
Feedback on the design doc is welcome on the PR.
02Bog Flow
Closed
No activity in this phase yet.
03Sludge Pulse
Editable. Press Enter to edit.
stack72 commented 6/17/2026, 5:04:58 PM
Revised Phase Breakdown
After critical review of the design doc (PR #1587), we've agreed on a tighter scope split. Key design decisions resolved:
- No break-glass — provider down = can't log in, same as Claude Code. Config edit + restart is the recovery path.
- Token lifetime ~30 days, configurable — but token expiry is garbage collection, not a security control. Explicit revocation is the primary mechanism and takes effect immediately.
- CEL conditions promoted to phase 1 — an admin managing a production environment needs attribute-based control (environment separation, self-service scoping) from day one. Name-globs alone force you to encode policy in naming conventions.
- Declarative grants file promoted to phase 1 — infra teams manage access through git, not imperative CLI commands.
- ACME deferred to phase 2 — static TLS behind a reverse proxy is sufficient for infra-operated deployments initially.
- Cost-bounding deferred to phase 2 — only needed when rule packs introduce untrusted third-party conditions. Phase 1 conditions are admin-authored (trusted). The sealed CEL environment in phase 1 is the invariant cost-bounding depends on later.
Phase 1 — "Who can run what"
- Static TLS — cert/key file paths in serve config
- Hard refusals — off-loopback without TLS or auth = won't start
- OAuth login — swamp-club as default provider, device authorization grant
- Server-minted tokens —
<name>.<secret>, hashed at rest, same shape as enrollment tokens - Admission policy —
allowedCollectivesandallowedUsersin serve config - Authorization — grants with name-glob selectors and CEL conditions: subject → action → resource → optional condition
- Sealed CEL environment — resource fields + principal context, no I/O, no extension functions, write-time type checking
- Local groups and IdP-asserted groups (collectives) as grant subjects
- Mandatory configured admin —
adminslist in config, materialized as grants at boot - Explicit revocation — immediate effect, in-memory policy snapshot invalidates on mutation
- Declarative grants file — checked into the repo, reconciled at startup,
source: file. Schema reserves room for apacks:key in phase 2. swamp accessCLI — grant create/list/revoke, group management,access check(admin explain mode for any subject),can-i(user self-service: what can I do, no admin required)- Server token default lifetime ~30 days, configurable
Phase 2 — "Harden and extend"
- ACME via
@fishballpkg/acme— HTTP-01, Let's Encrypt, renewal loop. Deferred because static TLS behind a reverse proxy is sufficient for the infra-operated deployments phase 1 targets. - CEL cost-bounding — AST depth, comprehension nesting, per-condition and aggregate cost budgets,
matches()regex complexity validation. Deferred because phase 1 conditions are authored by the admin, who is trusted. Required before rule packs because packs introduce untrusted conditions. - Rule packs — grants-as-data shipped by extensions, collective-scoped allow rules, global deny rules (with scope surfaced at enablement), inert until admin enables. Declarative grants file gains
packs:key. Deferred because admins can express the same grants via CLI or the declarative file. - Authorization code + PKCE — fallback for OAuth providers that don't support device grant. Deferred because swamp-club is the default provider and supports device grant, as do mainstream self-hosted IdPs.
- Server-side userinfo refresh — optional tighter IdP-group revocation on a cadence. Deferred because explicit revocation is the primary mechanism.
Remaining open question
- Whether swamp-club will expose a public OAuth 2.0 authorization server with the device grant + collectives on userinfo (lynchpin of phase 1 item 3, lives in the other repo).
stack72 commented 6/17/2026, 6:30:51 PM
Progress update
Layer 1 — completed
- ✅ #667 — Access bounded context (Grant, Group, shared value objects) — merged
Layer 1 — remaining
- ⬜ Sealed CEL grant environment (item 3)
- ⬜ AccessDecisionService (item 4) — blocked by items 1-3
- ⬜ Server token model (item 5)
- ⬜ Client credential storage (item 6)
Layer 2-6 — not started
- Layers 2-6 per the phase breakdown in the earlier ripple
stack72 commented 6/17/2026, 8:18:31 PM
Progress update
Layer 1 — completed
- ✅ #667 — Access bounded context (Grant, Group, shared value objects) — merged
- ✅ #670 — Sealed CEL grant-condition environment — merged
Layer 1 — remaining
- ⬜ AccessDecisionService (item 4) — unblocked, ready to start
- ⬜ Server token model (item 5)
- ⬜ Client credential storage (item 6)
Layer 2-6 — not started
stack72 commented 6/17/2026, 10:22:42 PM
Progress update
Layer 1 — completed
- ✅ #667 — Access bounded context (Grant, Group, shared value objects) — merged
- ✅ #670 — Sealed CEL grant-condition environment — merged
- 🔄 #672 — AccessDecisionService with in-memory policy snapshot — PR open
Layer 1 — remaining (items 5, 6 can start now in parallel)
- ⬜ Server token model (item 5)
- ⬜ Client credential storage (item 6)
Layer 2 — CLI and file loading (blocked by layer 1)
- ⬜ `swamp access` CLI — grant create/list/revoke, group management, `access check`, `can-i`
- ⬜ Declarative grants file — reconciliation at startup, `source: file`
- ⬜ Mandatory admin materialization from config
Layer 3 — TLS (no blockers)
- ⬜ Static TLS — cert/key paths in serve config
Layer 4 — Authentication (blocked by items 5, 6)
- ⬜ Auth config schema (`mode: none | token | oauth`)
- ⬜ `mode: token` support — server tokens authenticate connections
- ⬜ OAuth device grant flow — server-side OAuth client, userinfo exchange, admission policy
Layer 5 — Enforcement (blocked by layers 2 + 4)
- ⬜ Wire AccessDecisionService into serve chokepoints
- ⬜ `can-i` command (needs auth + access domain)
Layer 6 — Lock the door (last)
- ⬜ Hard refusals — off-loopback without TLS or auth = won't start
stack72 commented 6/17/2026, 10:49:27 PM
#672 — AccessDecisionService with in-memory policy snapshot — merged. Layer 1 core domain logic is now complete (items 1-4). Items 5 (server token model) and 6 (client credential storage) are ready to start, as is layer 3 (static TLS).
stack72 commented 6/18/2026, 1:10:36 PM
Layer 1 complete
All layer 1 items have merged:
- ✅ #667 — Access bounded context (Grant, Group, value objects)
- ✅ #670 — Sealed CEL grant-condition environment
- ✅ #672 — AccessDecisionService with in-memory policy snapshot
- ✅ #673 — Server token model
- ✅ #674 — Client credential storage
Layers 2, 3, and 4 are now unblocked.
stack72 commented 6/18/2026, 1:50:40 PM
Progress update
Layer 1 — complete ✅
- ✅ #667 — Access bounded context (Grant, Group, value objects)
- ✅ #670 — Sealed CEL grant-condition environment
- ✅ #672 — AccessDecisionService with in-memory policy snapshot
- ✅ #673 — Server token model
- ✅ #674 — Client credential storage
Layer 3 — complete ✅
- ✅ #675 — Static TLS (verified end-to-end: direct TLS + Caddy reverse proxy)
- ⬜ #677 — TLS documentation (no code, can be done anytime)
Layer 2 — ready to start
- ⬜ `swamp access` CLI — grant create/list/revoke, group management, `access check`, `can-i`
- ⬜ Declarative grants file — reconciliation at startup, `source: file`
- ⬜ Mandatory admin materialization from config
Layer 4 — ready to start
- ⬜ Auth config schema (`mode: none | token | oauth`)
- ⬜ `mode: token` support — server tokens authenticate connections
- ⬜ OAuth device grant flow — userinfo exchange, admission policy
Layer 5 — blocked by layers 2 + 4
- ⬜ Wire AccessDecisionService into serve chokepoints
- ⬜ `can-i` command
Layer 6 — last
- ⬜ Hard refusals — off-loopback without TLS or auth = won't start
stack72 commented 6/18/2026, 4:36:09 PM
Full project status
Layer 1 — Core domain ✅
- ✅ #667 — Access bounded context (Grant, Group, value objects)
- ✅ #670 — Sealed CEL grant-condition environment
- ✅ #672 — AccessDecisionService with in-memory policy snapshot
- ✅ #673 — Server token model
- ✅ #674 — Client credential storage
Layer 2 — CLI and file loading
- 🔄 #678 — `swamp access` CLI commands — implementation complete, needs commit + PR
- ⬜ Declarative grants file — not yet filed
Layer 3 — TLS ✅
- ✅ #675 — Static TLS — merged, verified end-to-end
Layer 4 — Authentication
- ⬜ Auth config schema (`mode: none | token | oauth`)
- ⬜ `mode: token` support
- ⬜ OAuth device grant flow
- ⬜ Mandatory admin materialization from config (depends on auth config schema)
Layer 5 — Enforcement
- ⬜ Wire AccessDecisionService into serve chokepoints
- ⬜ `can-i` command
Layer 6 — Lock the door
- ⬜ Hard refusals — off-loopback without TLS or auth = won't start
Documentation
- 🔄 #677 — TLS setup guide — in progress
- ⬜ #679 — Swamp serve user guide — after #677
stack72 commented 6/18/2026, 4:57:34 PM
#678 (swamp access CLI) and #677 (TLS setup guide) merged. Layer 2 has one remaining item: declarative grants file. Layer 4 (authentication) is next on the critical path.
stack72 commented 6/18/2026, 7:14:02 PM
Full project status
Layer 1 — Core domain ✅
- ✅ #667 — Access bounded context (Grant, Group, value objects)
- ✅ #670 — Sealed CEL grant-condition environment
- ✅ #672 — AccessDecisionService with in-memory policy snapshot
- ✅ #673 — Server token model
- ✅ #674 — Client credential storage
Layer 2 — CLI and remote management ✅
- ✅ #678 — `swamp access` CLI commands (grant/group/check)
- 🔄 #681 — Remote grant management via `--server` + explicit reload — PR open
#680— Declarative grants file — closed, replaced by #681 (remote management through control plane)
Layer 3 — TLS ✅
- ✅ #675 — Static TLS
Layer 4 — Authentication (ready to start)
- ⬜ Auth config schema (`mode: none | token | oauth`)
- ⬜ `mode: token` support — server tokens authenticate connections
- ⬜ OAuth device grant flow — userinfo exchange, admission policy
- ⬜ Mandatory admin materialization from config
Layer 5 — Enforcement (blocked by layer 4)
- ⬜ Wire AccessDecisionService into serve chokepoints
- ⬜ `can-i` command
Layer 6 — Lock the door (last)
- ⬜ Hard refusals — off-loopback without TLS or auth = won't start
Documentation
- ✅ #677 — TLS setup guide
- ⬜ #679 — Swamp serve user guide
stack72 commented 6/18/2026, 8:44:28 PM
#681 (remote grant management via --server + explicit reload) merged. Layer 2 complete. Layer 4 item 1 (#682, auth config schema) filed and ready to start.
stack72 commented 6/18/2026, 10:03:44 PM
#682 (auth config schema) and #683 (admin materialization) PRs open. Once both merge, we have everything needed for the end-to-end verification pass before starting mode: token (layer 4, item 2).
stack72 commented 6/19/2026, 1:33:39 AM
Full project status
Layer 1 — Core domain ✅
- ✅ #667, #670, #672, #673, #674
Layer 2 — CLI and remote management ✅
- ✅ #678, #681
Layer 3 — TLS ✅
- ✅ #675
Layer 4 — Authentication
- ✅ #682 — Auth config schema
- ✅ #683 — Admin materialization
- ✅ Bug fixes — CEL crash, truncated IDs, wildcard validation, noisy stack traces
- 🔄 #685 — `mode: token` authentication — PR open
- ⬜ OAuth device grant flow (blocked on swamp-club OAuth server work)
Layer 5 — Enforcement (blocked by #685)
- ⬜ Wire AccessDecisionService into serve chokepoints
- ⬜ `can-i` command
Layer 6 — Lock the door (last)
- ⬜ Hard refusals
Documentation
- ✅ #677 — TLS setup guide
- ⬜ #679 — Swamp serve user guide
- ⬜ CLI reference for access + token commands (tracking, no issue yet)
stack72 commented 6/19/2026, 2:04:16 PM
#685 (mode: token authentication) merged. Layer 4 token auth complete. Layer 5 (enforcement) is unblocked.
stack72 commented 6/19/2026, 2:35:59 PM
PRs open for final layers
- 🔄 #688 — Authorization enforcement at serve chokepoints — PR open
- 🔄 #689 — Hard refusals for off-loopback without TLS or auth — PR open
Once both merge, `mode: token` is fully functional end-to-end: authenticated connections, authorization enforcement, and safe-by-default binding. Ready for the demo setup (Caddy + local domain).
Remaining after these merge
- ⬜ `can-i` command (layer 5)
- ⬜ OAuth device grant flow (layer 4, blocked on swamp-club)
- ⬜ Documentation (#679 + CLI reference)
stack72 commented 6/19/2026, 2:57:46 PM
#688 (enforcement wiring) and #689 (hard refusals) merged. Layers 5 and 6 complete except for can-i command. Filing that now.
stack72 commented 6/19/2026, 4:47:07 PM
Phase 1 complete!
All phase 1 items have shipped. swamp serve now has a fully functional authenticated and authorized mode with `mode: token`.
Layer 1 — Core domain ✅
- ✅ #667, #670, #672, #673, #674
Layer 2 — CLI and remote management ✅
- ✅ #678, #681
Layer 3 — TLS ✅
- ✅ #675
Layer 4 — Authentication ✅
- ✅ #682, #683, #685
- ⬜ OAuth device grant flow (phase 1 complete without it — blocked on swamp-club)
Layer 5 — Enforcement ✅
- ✅ #688 — Authorization enforcement at chokepoints
- ✅ #690 — `can-i` command
Layer 6 — Lock the door ✅
- ✅ #689 — Hard refusals
Bug fixes ✅
- ✅ CEL crash on empty fields, truncated grant IDs, wildcard validation, noisy stack traces
Documentation
- ✅ #677 — TLS setup guide
- ⬜ #679 — Swamp serve user guide
- ⬜ CLI reference for access + token commands
Remaining (phase 2 / future)
- ⬜ OAuth device grant flow (swamp-club work: better-auth OAuth Provider + Device Authorization + Organization plugins)
- ⬜ ACME via `@fishballpkg/acme`
- ⬜ CEL cost-bounding
- ⬜ Rule packs
- ⬜ Auth code + PKCE fallback
- ⬜ Server-side userinfo refresh
stack72 commented 6/19/2026, 8:00:09 PM
Updated phase 1 scope
Phase 1 core auth is complete (layers 1-6). Three additional items added to phase 1 based on demo feedback — without these the feature isn't practical for daily use:
Phase 1 — remaining
- ✅ #702 — `SWAMP_SERVE_URL` env var — shipped
- ⬜ #703 — Global `--server` flag + remote paths for all CLI commands (`data get`, `data query`, `model list`, etc.)
- ⬜ #704 — `swamp access policy` alias for `swamp access grant`
- ⬜ #694 — `swamp access token rotate` command
- ⬜ #679 — Swamp serve user guide
Phase 2 — unchanged
- ⬜ OAuth device grant flow (swamp-club work)
- ⬜ ACME
- ⬜ CEL cost-bounding
- ⬜ Rule packs
- ⬜ Auth code + PKCE
- ⬜ Server-side userinfo refresh
stack72 commented 6/19/2026, 9:48:44 PM
Status update
Phase 1 — shipped
- ✅ Layers 1-6 — core auth complete
- ✅ Bug fixes — CEL crash, truncated IDs, wildcard validation, noisy traces, credential lookup, admin-implies-read
- ✅ #702 — SWAMP_SERVE_URL env var
- ✅ #694 — Token rotate command
- ✅ #704 — `swamp access policy` alias
Phase 1 — remaining
- ⬜ #703 — Global `--server` flag + remote paths for all CLI commands (`data get`, `data query`, `model list`, etc.)
- ⬜ #679 — Swamp serve user guide
Phase 2 — unchanged
- ⬜ OAuth device grant flow (swamp-club work)
- ⬜ ACME
- ⬜ CEL cost-bounding
- ⬜ Rule packs
- ⬜ Auth code + PKCE
- ⬜ Server-side userinfo refresh
stack72 commented 6/19/2026, 10:52:41 PM
Updated phase breakdown
Phase 1 — remaining
- ⬜ #710 — `--server` support for data/model/workflow/vault/audit/summary/report commands (priority 1-3 at minimum: data get, data query, data list, model list, workflow list)
- ⬜ #679 — Swamp serve user guide
Phase 2 — updated
- ⬜ OAuth device grant flow (swamp-club work: better-auth plugins)
- ⬜ ACME via `@fishballpkg/acme`
- ⬜ CEL cost-bounding
- ⬜ Rule packs
- ⬜ Auth code + PKCE fallback
- ⬜ Server-side userinfo refresh
- ⬜ `--server` long tail — remaining commands from #710 that don't ship in phase 1 (vault get/put, audit, summary, report, model method describe, workflow describe, and any others discovered)
stack72 commented 6/21/2026, 7:32:14 PM
Phase 1 complete!
All phase 1 functional work has shipped.
Phase 1 — shipped ✅
- ✅ Layer 1 — Core domain (#667, #670, #672, #673, #674)
- ✅ Layer 2 — CLI + remote management (#678, #681)
- ✅ Layer 3 — Static TLS (#675)
- ✅ Layer 4 — Auth config (#682), admin materialization (#683), mode: token (#685)
- ✅ Layer 5 — Enforcement (#688), can-i (#690)
- ✅ Layer 6 — Hard refusals (#689)
- ✅ UX — SWAMP_SERVE_URL (#702), token rotate (#694), policy alias (#704)
- ✅ Remote commands — --server for all data/model/workflow/vault/audit/summary/report commands (#710)
- ✅ Security fix — canonicalization mismatch in isAccessModelType
- ✅ Bug fixes — CEL crash, truncated IDs, wildcard validation, noisy traces, credential lookup, admin-implies-all
- ✅ Docs — TLS setup guide (#677)
Phase 1 — remaining
- ⬜ #679 — Swamp serve user guide
Phase 2
- ⬜ OAuth device grant flow (swamp-club work: better-auth plugins)
- ⬜ ACME via `@fishballpkg/acme`
- ⬜ CEL cost-bounding
- ⬜ Rule packs
- ⬜ Auth code + PKCE fallback
- ⬜ Server-side userinfo refresh
- ⬜ #711 — --server long tail (remaining remote-capable commands)
stack72 commented 6/21/2026, 7:35:51 PM
ACME dropped from phase 2. Static TLS (--cert-file/--key-file) covers corporate PKI. Caddy covers auto-provisioned TLS with one command. Building an ACME client into swamp adds complexity for no real benefit over the Caddy approach already documented in #677.
stack72 commented 6/22/2026, 10:11:11 PM
Phase 1 complete — guide is the last item
All code, security hardening, and verification done:
- ✅ All layers shipped (core domain, CLI, TLS, auth, enforcement, hard refusals)
- ✅ All security fixes (canonicalization, rate limiting, error sanitization, token size limits, CEL timeout, symlink protection, etc.)
- ✅ 99 manual verification tests passed (0 failed) across authentication, authorization, bypass prevention, CEL conditions, privilege escalation, token rotation, input validation, and information leak prevention
- ✅ Bug bounty response handled
Phase 1 — remaining
- ⬜ #679 — Swamp serve user guide (last item)
Phase 2
- ⬜ OAuth device grant flow (swamp-club work)
- ⬜ CEL cost-bounding
- ⬜ Rule packs
- ⬜ Auth code + PKCE fallback
- ⬜ Server-side userinfo refresh
- ⬜ #711 — --server long tail
stack72 commented 6/23/2026, 6:07:08 PM
Phase 1 complete 🎉
All phase 1 work has shipped:
Code
- ✅ Layers 1-6 (core domain, CLI, TLS, auth, enforcement, hard refusals)
- ✅ Remote --server support for all data/model/workflow/vault/audit/summary/report commands
- ✅ UX (SWAMP_SERVE_URL, token rotate, policy alias)
- ✅ Origin/Host validation on WebSocket upgrade (CSWSH prevention)
- ✅ auth-mode none deprecation warning
Security
- ✅ Canonicalization fix (isAccessModelType)
- ✅ Rate limiting, token size limits, generic auth errors
- ✅ Error message sanitization, request ID limits
- ✅ CEL timeout detection, symlink protection
- ✅ Fire-and-forget rebuild fix, snapshot debouncing
- ✅ Origin/Host validation for CSWSH/DNS rebinding prevention
- ✅ 99 manual security verification tests passed
Documentation
- ✅ TLS setup guide (#677)
- ✅ Swamp serve user guide (#679) — 12 pages across how-to, reference, and explanation sections
Bug bounty reports handled
- SWAMP-001: canonicalization bypass (Low, $250)
- SWAMP-005: CSWSH/DNS rebinding (Low, no bounty — config being deprecated)
Phase 2 remains
- ⬜ OAuth device grant flow (swamp-club work)
- ⬜ CEL cost-bounding
- ⬜ Rule packs
- ⬜ Auth code + PKCE fallback
- ⬜ Server-side userinfo refresh
- ⬜ #711 — --server long tail
stack72 commented 6/29/2026, 11:12:39 PM
Phase 1 fully complete + #711 long tail shipped
- ✅ #711 — --server support for all remaining commands (52/52 live tests passed)
- ✅ #890 — Token auth fix (path resolution mismatch in serve deps)
- ✅ PolicySnapshotLoader report artifact noise fix
- ✅ Host validation fix for reverse proxy deployments
Phase 2 starts tomorrow.
stack72 commented 7/8/2026, 12:25:21 AM
Phase 2 Track A — OAuth device grant flow — SHIPPED
swamp-club
- ✅ #1015 — OIDC Provider + Device Authorization plugins, collective-based userinfo, bootstrap client, device verification page, admin OAuth client management, resolve-user endpoint
swamp
- ✅ #1016 — mode: oauth device grant client, bootstrap registration, admission policy, collective wiring into enforcement, admin username resolution, auth server-login command
Security
- ✅ Security review completed (Fable) — 1 HIGH + 3 MEDIUM + 3 LOW findings, all addressed
- ✅ Default-open admission fixed (requires --allowed-collectives or --allowed-users)
- ✅ Bootstrap access token no longer persisted
- ✅ Admin resolution heuristic removed (always resolve, fail hard on error)
- ✅ Bootstrap client rate-limited
- ✅ Non-HTTPS provider rejected (except localhost)
Documentation
- 🔄 #1026 — OAuth how-to + explanation docs — PR open
Verified end-to-end
- ✅ Bootstrap registration (first boot, device flow, auto-register)
- ✅ Subsequent boot (credentials from vault, skip registration)
- ✅ Admin login via device grant
- ✅ Admin operations (can-i, grant list, model run)
- ✅ Outsider rejected (not in allowed collective)
- ✅ Admin re-login after outsider rejection
stack72 commented 7/8/2026, 12:35:14 AM
Updated status
Phase 1 ✅ complete
Phase 2 — Track A ✅ complete
- ✅ #1015, #1016 — OAuth device grant flow shipped
- ✅ #1026 — OAuth docs shipped
- ✅ #711 — --server long tail shipped
Phase 2 — remaining
- ⬜ Track B: CEL cost-bounding → rule packs
- ⬜ SSO + IdP group federation (swamp-club side — install @better-auth/sso, per-customer IdP connections, store IdP groups on user, surface on userinfo)
- ⬜ Server-side userinfo refresh (automatic group refresh on a cadence)
- ⬜ Auth code + PKCE fallback (defer until needed)
stack72 commented 7/8/2026, 12:37:36 AM
Auth Code + PKCE dropped permanently. swamp-club is the only supported OAuth provider (all SSO integration happens via swamp-club). Since swamp-club supports the device grant, there's no need for a fallback flow.
Phase 2 — remaining
- ⬜ Track B: CEL cost-bounding → rule packs
- ⬜ SSO + IdP group federation (swamp-club side — when customer demand exists)
- ⬜ Server-side userinfo refresh (depends on SSO)
stack72 commented 7/8/2026, 6:37:40 PM
Phase 2 status update
Track A: OAuth ✅ complete
- ✅ #1015 — swamp-club OAuth provider
- ✅ #1016 — swamp serve OAuth client + collective-based admission
- ✅ #1026 — OAuth docs
- ✅ Security review — all findings addressed
Track B: CEL cost-bounding ✅ complete
- ✅ #1029 — AST depth, comprehension nesting, cost budget, matches() validation, aggregate decision budget
Phase 2 — remaining
- ⬜ Rule packs (unblocked by #1029)
- ⬜ SSO + IdP group federation (when customer demand exists)
- ⬜ Server-side userinfo refresh (after SSO)
stack72 commented 7/8/2026, 9:43:08 PM
Phase 2 status update
Track A: OAuth ✅ complete
Track B: CEL cost-bounding ✅ complete
Declarative grants ✅ complete
- ✅ #1037 — grants/ directory with validate-and-reconcile on reload
Phase 2 — remaining
- ⬜ Rule packs (extensions shipping grants — use case 2, needs design discussion)
- ⬜ SSO + IdP group federation (when customer demand exists)
- ⬜ Server-side userinfo refresh (after SSO)
stack72 commented 7/8/2026, 11:26:42 PM
Full status
Phase 1 ✅ complete
Phase 2 ✅ largely complete
Shipped:
- ✅ Track A — OAuth device grant flow (#1015, #1016, #1026)
- ✅ Track B1 — CEL cost-bounding (#1029)
- ✅ Declarative grants directory (#1037)
- ✅ Declarative grants docs (#1046)
Remaining:
- ⬜ Rule packs (use case 2 — extensions shipping grants, needs design)
- ⬜ SSO + IdP group federation (when customer demand exists)
- ⬜ Server-side userinfo refresh (after SSO)
stack72 commented 7/8/2026, 11:30:01 PM
Rule packs dropped from scope. The declarative grants directory (#1037) covers the real need — policy as files, reviewed in PRs, applied on reload. Extension authors can ship sample grant files in their docs for admins to adapt. The complexity of extension-bundled policy (collective scoping, enablement lifecycle, trust boundary) isn't justified without customer demand.
Remaining
- ⬜ SSO + IdP group federation (when customer demand exists)
- ⬜ Server-side userinfo refresh (after SSO)
stack72 commented 7/9/2026, 11:08:18 PM
Status update
- ✅ #1048 — Swamp skill updated with serve, grants, and access control guidance
Agents now have full guidance on grant authoring (CLI + declarative files), auth modes, access checking, token management, and OAuth login.
#662 remaining
- ⬜ SSO + IdP group federation (when customer demand exists)
- ⬜ Server-side userinfo refresh (after SSO)
Both are customer-driven. The serve auth system is functionally complete.
Sign in to post a ripple.