7de5c74500
- open-questions #7: symmetric vs. asymmetric JWT signing key (from the commit security review). Prefer RS256/EdDSA so verifying hosts hold only a public key — mirrors the ATECC608 / challenge-response "public key only" property. Decide before multi-host/multi-lane deployment. - Mark esp32-custom-controller status: deferred per decision not to build device-level auth now; access control stays on UHPPOTE + network isolation (noted in open-questions #6). - local-jwt-auth: document hardened secret handling + 8h expiry and the asymmetric-key pointer. - Update index.md and append a log.md entry.
1.2 KiB
1.2 KiB
type, tags, sources, updated
| type | tags | sources | updated | |||||
|---|---|---|---|---|---|---|---|---|
| entity |
|
|
2026-06-15 |
Local JWT Auth
Authentication and authorization, kept fully local — a direct consequence of offline-first (an air-gapped park cannot reach an external identity provider; see logto-zitadel-oidc for the rejected alternative). (See parking-system-architecture §2.)
@fastify/jwtsigns tokens with a local secret (symmetric HMAC). The server refuses to start without a strongJWT_SECRET(≥32 chars, no placeholder) — there is deliberately no insecure default — and mints tokens with an 8h expiry (bound to a shift).- A
userstable in sqlite holds bcrypt password hashes plus a role column. - Authorization = a simple
preHandlerrole guard per route: admin / operator / cashier / readonly. No Casbin or full RBAC engine needed at this scale.
Open decision: moving from the symmetric secret to an asymmetric key (RS256/EdDSA) so verifying hosts hold only a public key — open-questions #7. Relevant before any multi-host/multi-lane deployment.
Part of the technology-stack. License: MIT.