Files
parking_solution/wiki/entities/local-jwt-auth.md
T
julian 7de5c74500 wiki: record JWT key open question; defer ESP32 controller
- 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.
2026-06-14 07:45:14 +02:00

1.2 KiB

type, tags, sources, updated
type tags sources updated
entity
parking
stack
auth
offline-first
parking-system-architecture
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/jwt signs tokens with a local secret (symmetric HMAC). The server refuses to start without a strong JWT_SECRET (≥32 chars, no placeholder) — there is deliberately no insecure default — and mints tokens with an 8h expiry (bound to a shift).
  • A users table in sqlite holds bcrypt password hashes plus a role column.
  • Authorization = a simple preHandler role 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.