ProviderConnection with encrypted credentials #5

New Issue

GKaszewski · 2026-08-26T09:13:17Z

GKaszewski commented

2026-08-26 09:13:17 +00:00

What to build

Implements ADR 0005. A ProviderConnection is a User's standing authorization to a named Provider, held as an opaque credential encrypted under a key from the environment.

The domain does not know what a Provider is or how it is reached. It holds a name and an opaque credential; parsing, authenticating, and calling are entirely adapter concerns. That is what lets a second Provider with a different credential shape (OAuth, API key) be added later without touching the domain.

The risk is accepted knowingly and recorded in the ADR: the classic Subsonic scheme computes a per-request token from the plaintext password, so the stored secret is password-equivalent. Encryption raises the bar against a stolen database file alone; it buys little if environment and data are backed up together.

The encryption key follows the existing convention for secrets — environment, not the TOML config file, alongside the JWT secret.

Acceptance criteria

A User can connect and disconnect a named Provider from settings
Credentials are encrypted at rest; the plaintext never appears in the database or in logs
The encryption key is read from the environment and its absence is a clear startup failure, not a silent fallback
The domain type exposes only a Provider name and an opaque credential
Connection status is visible in settings without exposing the credential
Adding a second Provider with a different credential shape needs no domain change

Blocked by

None - can start immediately.

## What to build Implements ADR 0005. A `ProviderConnection` is a User's standing authorization to a named `Provider`, held as an opaque credential encrypted under a key from the environment. The domain does not know what a `Provider` is or how it is reached. It holds a name and an opaque credential; parsing, authenticating, and calling are entirely adapter concerns. That is what lets a second `Provider` with a different credential shape (OAuth, API key) be added later without touching the domain. The risk is accepted knowingly and recorded in the ADR: the classic Subsonic scheme computes a per-request token from the plaintext password, so the stored secret is password-equivalent. Encryption raises the bar against a stolen database file alone; it buys little if environment and data are backed up together. The encryption key follows the existing convention for secrets — environment, not the TOML config file, alongside the JWT secret. ## Acceptance criteria - [ ] A User can connect and disconnect a named `Provider` from settings - [ ] Credentials are encrypted at rest; the plaintext never appears in the database or in logs - [ ] The encryption key is read from the environment and its absence is a clear startup failure, not a silent fallback - [ ] The domain type exposes only a `Provider` name and an opaque credential - [ ] Connection status is visible in settings without exposing the credential - [ ] Adding a second `Provider` with a different credential shape needs no domain change ## Blocked by None - can start immediately.

GKaszewski added the ready-for-agent label 2026-08-26 09:13:17 +00:00

GKaszewski referenced this issue

2026-08-26 09:14:13 +00:00

Song dimension with Subsonic now-playing and MusicBrainz enrichment #11

GKaszewski closed this issue

2026-08-26 11:23:05 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GKaszewski/k-mood#5