Add Authentication

[FireSquid6]

Authentication for fleet should happen in several places:

Both the ship and the bridge should check Authorization: headers.

Outside to Bridge

All communications to the bridge should include a bearer token that identifies itself as a session to a specific user. Store users and sessions in a managed bun:sqlite database (abstract this into a Database class that manages and validates).

Users should either have the role member or admin. Admins can create other users, members cannot.

Additionally, store a version table in the database with one column version with one row storing it as 1 for now. We will use this later if the database needs to be updated.

Note down for future agents that the database should only be for authentication related items and the store should handle everything else.

When testing, you should use an ephemeral memory database.

To prevent lockout, if a fleet bridge is being launched and a user is not detected, it should through stdin ask for a username and password to setup the first user as.

Ship to Bridge

Each ship should have its own FLEET_SHIP_TOKEN that's shared by the bridge and ship. The bridge will always provide the FLEET_SHIP_TOKEN when sending messages to the ship, and the ship will always provide it to the bridge when sending messages to it.

All tokens should be able to be configured with fleet launch

Important: scope it as narrowly as possible for SHIP -> BRIDGE calls. We don't want one compromised ship to compromise the whole bridge.

Web Client

The web client should support signing in and storing the session token.

Client CLI

The CLI should also store the session in ~/.local/state/fleet-client-cli/{url-of-bridge}/... If it doesn't exist, then the cli should prompt in stdin for the username and password to authenticate with.

[FireSquid6]

@claude possible flaws with this auth implementation?

[claude]

Claude finished @FireSquid6's task in 26s —— View job

---

Tasks

• Read issue and repo context
• Check current state of auth implementation in the codebase
• Analyze the proposed auth design for flaws
• Post findings

Context

I checked the repo first — auth is currently greenfield. fleet-bridge, fleet-ship, fleet-client, and the CLI have no auth/session/token/database code today; both fleet-bridge and fleet-ship run Elysia apps with fully open routes (no .guard()/.derive()/beforeHandle auth checks anywhere), and no bun:sqlite usage exists yet outside of CLAUDE.md guidance. So this is a review of the design as written in the issue, not of existing code.

Possible flaws / gaps in the design

Bootstrap ("no user detected → prompt on stdin")

• If "no user detected" is the trigger condition on every launch, a bridge run as a daemon/service (no TTY, e.g. under systemd or a container) will hang or crash on stdin read. Needs a non-interactive fallback (env var / flag) for headless deploys.
• If the "detect no users" check and the "create first user" write aren't done atomically, two concurrent bridge processes pointed at the same DB file could race and both prompt / both insert a first admin. Worth wrapping in a transaction or file lock.
• Consider what happens if the only admin account is later deleted — is there a way to re-trigger bootstrap, or is that itself the lockout-recovery path?

Passwords & tokens

• The issue doesn't specify a hashing scheme — passwords must be hashed with a slow, salted algorithm (Bun has Bun.password.hash, which defaults to argon2id) — never plain/reversible storage.
• Session tokens should be high-entropy, cryptographically random (not Math.random/incrementing IDs), and ideally stored hashed in the sqlite sessions table (like passwords) so a DB dump/leak doesn't hand out live sessions directly.
• Token/password comparisons on the Authorization header should be constant-time to avoid timing side-channels.
• No mention of session expiry, revocation, or logout — sessions should have a TTL and a way to invalidate them (e.g., on password change or explicit logout), otherwise a leaked bearer token is valid forever.
• No mention of login rate-limiting/lockout — without it, the bearer/password endpoint is brute-forceable. Error responses should also avoid revealing whether a username exists ("invalid credentials", not "user not found").

FLEET_SHIP_TOKEN (ship ↔ bridge)

• As described, the same shared token is used bidirectionally ("bridge will always provide the token... ship will always provide it to the bridge"). That means a leaked/compromised ship also leaks a credential valid for the bridge → ship direction, not just ship → bridge. Since the issue explicitly calls out wanting to contain a compromised ship, consider distinct tokens per direction, or asymmetric auth (ship holds a keypair; bridge verifies a signature) so a compromised ship can't impersonate the bridge to itself or (if tokens are ever reused) to other ships.
• "Configured with fleet launch" — if this token is ever accepted as a CLI argument, it'll leak via shell history and ps aux. Prefer env var or a config file with restricted permissions (0600).
• "Scope it as narrowly as possible" is stated as a goal but the design doesn't yet say how — this needs its own principal/role (distinct from member/admin) so a ship's token can only hit the small set of ship-facing endpoints for that ship, not the general admin/user API surface.

Web client & CLI session storage

• If the web client stores the bearer token in localStorage, it's readable by any injected/XSS script. An httpOnly cookie (with Secure/SameSite) is safer, though that then requires CSRF protection since cookies are auto-attached. Worth deciding explicitly rather than defaulting to localStorage.
• The CLI's ~/.local/state/fleet-client-cli/{url}/... session file should be created with 0600 permissions so other local users/processes can't read the token off disk.

Role model

• Only two roles (member/admin), both apparently with equal access to all ships/workspaces. If ships vary in sensitivity, an all-or-nothing member role may be over-permissioned — not a hard requirement from the issue, but worth a conscious decision rather than an accident of the schema.

General

• No mention of requiring TLS — bearer tokens (session or FLEET_SHIP_TOKEN) sent over plain HTTP are sniffable on the wire. Worth documenting the trust assumption (e.g. "assumes a private network" or "TLS required in production").

None of these are blockers to starting the implementation — they're refinements to bake in from the start (hashing, token expiry/rotation, scoping, storage location) so they don't need retrofitting later. No code was changed as part of this task since the request was to review the design, not implement it.