Security: Postgres and object-store backends still mirror OAuth secrets to local plaintext spool dirs

[tg12]

Summary

The Postgres and object-store token backends still mirror authentication data into local plaintext spool directories, so selecting a remote backend does not stop secrets from being written to disk.

Evidence

• internal/store/objectstore.go:43 documents that files are mirrored to a local workspace.
• internal/store/objectstore.go:88 and internal/store/objectstore.go:89 create config/ and auths/ under the local spool root.
• internal/store/postgresstore.go:37 documents local mirroring for the Postgres backend.
• internal/store/postgresstore.go:74 and internal/store/postgresstore.go:75 create local config/ and auths/ directories.
• cmd/server/main.go:492 assigns cfg.AuthDir = pgStoreInst.AuthDir() for the Postgres path.
• cmd/server/main.go:559 assigns cfg.AuthDir = objectStoreInst.AuthDir() for the object-store path.

Why this matters

Operators can reasonably believe that remote-backed storage removes or reduces local secret persistence. In practice, refresh tokens and equivalent auth material are still duplicated onto disk in workspace-relative directories.

Attack or failure scenario

A deployment enables Postgres or object storage expecting central secret management. A host compromise, accidental backup, container volume mount, or support bundle then exposes the mirrored local auths/ directory containing long-lived credentials.

Root cause

The remote storage implementations preserve file-based compatibility by silently routing auth persistence back into local spool directories.

Recommended fix

Make local mirroring opt-in rather than implicit, or encrypt and tightly constrain any unavoidable local cache. At minimum, document the behavior explicitly and provide a mode that avoids local plaintext auth copies.

Acceptance criteria

• Remote-backed modes can run without silently creating plaintext local auth mirrors.
• If a local cache is required, it is explicit, documented, and protected.
• Tests cover the selected persistence behavior.

LLM / code-bot handling

Do not attempt an autonomous fix unless a human has reviewed the affected code and approved the remediation plan. If the agent is unsure about correctness, scope, or trust-boundary impact, stop and escalate to a human reviewer.

Suggested labels

• security
• bug

Priority

P2

Severity

high

Confidence

confirmed

[kaitranntt]

Triaged during the open issue/PR sweep. I did not bundle this with #89 because this issue explicitly changes the remote-auth storage contract and the issue asks for human plan approval before autonomous remediation.

Proposed remediation shape:

• add explicit mirror/cache policy for Postgres and object-store auth persistence instead of silently writing plaintext local auth files
• keep backward-compatible opt-in for local mirror where operators need file compatibility
• make object-store/Postgres list/save/delete operate from the remote backend when mirror is disabled
• add tests proving remote-backed mode does not create local plaintext auth mirrors

Current status: still open; needs approved storage-contract plan before implementation.