Status: Accepted (documented from implementation)
Applies to: every deployment of the clarity binary (all topologies)
Related: API Server, Security Model
The backend signs client JWTs with a symmetric secret. A hardcoded default secret would let anyone forge tokens, but requiring an env var at every launch is awkward for an installed desktop/edge binary.
JWT_SECRET is resolved by a lazy_static! that prefers the runtime env var and falls back to a value baked in at compile time:
env::var("JWT_SECRET")
.map(|s| s.into_bytes())
.unwrap_or_else(|_| {
env!("JWT_SECRET", "JWT_SECRET must be exported before running cargo build (see build.sh)")
.as_bytes().to_vec()
})
clarity:backend/src-tauri/src/auth.rs:28-41Because env! is a compile-time macro, a build with no JWT_SECRET exported fails to compile (build.sh exports it). There is no plaintext default in the source, and no runtime startup panic for a missing variable — a built binary already carries the secret, and a runtime env var can override it.
Supporting facts:
auth_jwt_expiry_seconds: 86400, config.rs:261); create_jwt sets exp from this, or 0 when never_expires is requested — auth.rs:108-116.auth.rs:74-105.blake3 fingerprint of the secret is gossiped on the HA heartbeat to warn about mismatches — auth.rs:43-51.clarity:backend/src-tauri/src/auth.rs:28-41, :43-51, :74-105, :108-116clarity:backend/src-tauri/src/config.rs:261Last updated: 2026-06-02 from clarity@498c020