docs(swarm): point sso.md's secrets section at secrets.md instead of restating it

This commit is contained in:
iris 2026-08-15 11:44:49 +02:00 committed by mara
commit b02af39007

View file

@ -91,22 +91,12 @@ an attribute edit can invalidate a login by accident.
## What secrets exist, and where each one lives ## What secrets exist, and where each one lives
Every secret in the swarm, with its generator and its path, is tabulated Every secret in the swarm, with its generator and its path, is tabulated
in one place: [`secrets.md`](secrets.md). The rows relevant here are in one place: [`secrets.md`](secrets.md), including authelia's own keys
authelia's own keys (session, JWT, storage-encryption, OIDC HMAC, OIDC (session, JWT, storage-encryption, OIDC HMAC, OIDC issuer) and the two
issuer) plus the two halves of each client secret. halves of each client secret. That page's two rules — a secret is always
a path, never a value, and the generator and the reader are usually in
What matters for this page is the shape rather than the paths. Authelia's different containers — are why the client secret's plaintext half needs
own keys are generated **in-container**, because nothing outside that the delivery step below and the rest of authelia's keys don't.
container ever reads them — that is the test worth applying to any secret
added here. The plaintext half of a client secret is the one that fails
it: its reader lives in a different container, and that is the entire
reason a delivery step exists.
**None of it is ever written into a nix expression.** authelia's
`settings` are rendered into the nix store, which is world-readable and
permanent, so the client digest reaches authelia through `settingsFiles`
(merged at runtime) and every other secret through a `*File` option
carrying a path rather than a value.
## Getting the plaintext to the relying party ## Getting the plaintext to the relying party