feat(security): Wrap secrets with secrecy crate (#369)

[ymh1874]

TL;DR

Wraps every remaining plaintext secret in the codebase — the OIDC
client_secret, user/auth passwords (all the way up to the wire), the config
invalid_password_hash_key, and the OIDC token-exchange bearer tokens — in
secrecy::SecretString, so they can never leak through Debug,
#[tracing::instrument], or accidental serialization. Secrets that must appear in
OPA policy / audit payloads are redacted to "[REDACTED]" instead of exposed.
Along the way this fixes three pre-existing plaintext leaks into OPA policy
input and closes an empty-password acceptance gap. The public OpenAPI schema
is byte-for-byte unchanged, and the change is covered by an adversarial
redaction/breakage test suite. Part of #369; delivered as one PR because touching
api-types pulls through every downstream crate.

---

Background

secrecy was already a workspace dependency with an established pattern
(database.connection: SecretString), and passwords were already wrapped at the
provider/backend layers. This PR closes the remaining gaps the audit found and
lifts the wrapping to a consistent edge-to-consumer boundary: a secret is
SecretString from the moment it is deserialized off the wire (or read from the
DB) until the single point where it is genuinely consumed (hash / verify / HTTP
form / DB write), where it is explicitly .expose_secret()'d.

What is wrapped (edge → consumer)

Secret	Layers touched
OIDC oidc_client_secret	api-types DTO → core-types (3 structs) → SQL driver conversions → token-exchange consumer. oidc_client_id stays plaintext (per maintainer).
User / auth passwords	UserCreate / UserUpdate / UserPassword + the full nested AuthRequest tree, and the mirror core-types domain structs, are now SecretString from deserialize down. Exposure happens only at hash_password / verify_password / validate_password.
Config invalid_password_hash_key	SecurityComplianceProvider (mirrors database.connection).
OIDC id_token / access_token	TokenExchangeResponse bearer tokens, previously plaintext String in a Debug-deriving struct; exposed only at the JWT-verify boundary.

Redaction, not exposure

SecretString intentionally does not implement Serialize. For the DTOs that
must stay serializable (they are embedded in OPA policy input / audit payloads),
a serialize_with helper renders a present secret as a fixed "[REDACTED]"
marker — field presence is preserved, the value never leaves. This is deliberately
different from the existing "expose once" helper used for the one-time API-key
token (that one is part of the API contract).

Pre-existing leaks this fixes

json!({"identity_provider": current}), json!({"user": req.user}) (and the
create/update variants) serialize the domain/DTO structs straight into OPA
policy input. Before this PR those payloads contained the plaintext
oidc_client_secret and user password. They now redact.

Security hardening — empty-password guard

Wrapping the password meant the per-DTO length(min = 1) validation could not be
kept: validator 0.20's custom unconditionally calls
ValidationError::add_param(&field), which requires the field to be Serialize —
and secrets deliberately are not. Without that guard, on a default deployment
(no password_regex) an empty password would be accepted and stored (bcrypt
hashes an empty string fine).

Fixed by moving the non-empty check into the correct central layer —
SecurityComplianceProvider::validate_password — which runs on the wrapped value
for every write path (create / update / change). This is strictly more secure
than before (previously only create was guarded).

Design decisions / notes

• Sea-ORM oidc_client_secret column stays plaintext String. Wrapping the
  DB column would require custom TryGetable / Into<Value> impls and would not
  stop SQL-parameter-level logging anyway; the DB write is the final consuming
  method, where the secret is unwrapped.
• PartialEq / Default are dropped from the wrapped structs where nothing
  relies on them (matching the existing app-cred / k8s pattern), and
  re-implemented manually where tests do rely on them (IdentityProvider
  read model; UserPasswordAuthRequest), preserving the prior public contract.
• OpenAPI unchanged. #[schema(value_type = String / Option<String>)] keeps
  every wrapped field documented exactly as before; the generated spec has zero
  structural diff vs main.
• validator + SecretString are fundamentally incompatible for field-level
  length/custom validation (see the empty-password section) — documented inline so
  a future pass doesn't reintroduce it.

Testing & verification

• cargo check --workspace --all-targets --all-features ✅
• cargo clippy --lib --tests --all-features ✅ · cargo fmt --check ✅
• Full unit/lib suite green (no regressions): api-types, core-types, config, core,
  keystone, and the SQL drivers.
• OpenAPI: regenerated and diffed against main — 0 structural changes.
• Adversarial redaction / breakage test suite added, covering:
  • #[serde(flatten)] extra + custom serialize_with + skip on UserCreate /
    UserUpdate (the exact struct serialized to OPA) — password redacted, extra
    preserved, via both to_string and to_value.
  • Deep-nested AuthRequest serialize redaction (password 4 levels deep).
  • OPA-path redaction for the user + IdP create/update DTOs.
  • Empty-password rejected without a regex (regression guard).
  • Debug redaction matrix across every wrapped type, incl. the config hash key.
  • IdP response DTO can never expose a client secret.
  • OIDC bearer-token Debug redaction; deserialize edge cases (null / absent).
• Every .expose_secret() call site re-audited — none feeds a log / print /
  format; each is a genuine consume boundary (hash, verify, DB write, HTTP form,
  JWT verify).

Out of scope (follow-up #370)

The credential blob (EC2 secret key / TOTP seed material) is also a secret but is
outside the maintainer's stated scope for this effort; left as a follow-up so it
isn't silently dropped.

🤖 Generated with Claude Code

[ymh1874]

Thanks for the review. I reworked the secret handling around a single RedactedSecret newtype in core-types (redacts on Debug/Serialize, derives PartialEq/Serialize/Deserialize on the owning struct). That let me:

• delete secret_serde.rs and the duplicated core-types serializer,
• drop the hand-written PartialEq for IdentityProvider (it derives again, so new fields are picked up automatically),
• wrap the remaining plaintext secrets (passcode, TokenAuth.id),
• trim the repetitive docstrings and relax the redaction tests to only assert plaintext absence.

api-types now depends on core-types directly (previously optional) so both layers share the type; every existing consumer already enabled builder/conv, so the only new edge is cli-manage picking up the pure-types crate. Individual replies inline. cargo build/clippy --lib --tests/tests all green.

[gtema]

this is not necessary and makes no sense (passing masked input where it should be skipped completely). Technically I would rather convert the whole struct to Value and remove secrets out of it. It is much shorter. The same would apply to every other case

[ymh1874]

Done in 7c360743 — to_policy_input() now omits the secret entirely instead of masking it with [REDACTED], for UserCreate/Update and IdentityProviderCreate/Update.

[gtema]

problem is that now you ONLY validate a single field dropping validation of all other fields. Instead you can attach a specific validation function to a field directly.

[ymh1874]

A field-level #[validate(custom)] can't be attached to a SecretString: validator 0.20 calls err.add_param("value", &field) on failure, which requires Serialize — it won't compile and would serialize the secret into the error. So I kept #[derive(Validate)] (every non-secret field is still validated) and check only the secret via a struct-level schema fn that never serializes it, documented with a NOTE inline. Added a test that an over-long non-secret field (e.g. name) still fails. 7c360743

[gtema]

same issue with the validation as above

[ymh1874]

As above.

[gtema]

as mentioned above - the field should simply not appear at all in the policy data

[ymh1874]

As above — the secret key no longer appears in the policy data.

[gtema]

same issue with broken validation

[ymh1874]

As above.

[gtema]

we should not expose secret here, but pass it down. This signals that upa.password must also be converted to SecretString

[ymh1874]

Done in 7c360743 — the conversion passes the SecretString down instead of exposing it at conversion time.

[gtema]

validation

[ymh1874]

As above.

[gtema]

and here

[ymh1874]

As above.

[gtema]

also this validators can be placed to common for reuse

[ymh1874]

The api-types and core-types copies are separate because each crate gates validation behind its own validate feature, so a shared module would couple the feature sets. Happy to extract one if you'd prefer.

[gtema]

again validation

[ymh1874]

As above.