Authentication

SafeCall uses JWT (JSON Web Tokens) with RS256 for authentication. The auth system is implemented across lib/src/jose.ts (JWT operations) and server/src/guard.ts (request guards).

JWT Flow

1. Server generates an RS256 key pair at startup
2. Public key is exposed via /.well-known/jwks.json
3. Users authenticate via POST /login with email/password
4. Server returns a signed JWT containing user ID and admin status
5. Clients include the JWT in Authorization: Bearer <token> headers
6. Guards verify the JWT on protected routes

Key Configuration

Key	Default	Description
server_auth_jwt_issuer	https://auth.wantok.cz	JWT issuer claim
server_auth_jwt_audience	https://auth.wantok.cz	JWT audience claim
server_auth_jwt_expiry	8h	Token expiry duration

Request Guards

Guards are used in HTTP route handlers to enforce access control. They are defined in server/src/guard.ts:

guard_admin(req)

Verifies the request has a valid JWT with admin privileges. Returns { db, jose_keys } on success or a 403 response on failure.

guard_auth(req)

Verifies the request has a valid JWT (any user). Returns { db, jose_keys, user_id, is_admin } on success or a 403 response on failure.

guard_db(req)

Only checks that the database is ready. Returns { db } or a 400 response. Used for unauthenticated endpoints that need database access.

Navigation Tokens

For mobile navigation, the server supports read-only navigation tokens as an alternative to JWT. These are managed via the /navigation/tokens endpoints and allow mobile users to access navigation data without a full user account.

Navigation tokens use Authorization: Token <token> instead of Bearer.

Default Credentials

On first install, a default admin user is created:

• Email: configured via server_credentials_default_email
• Password: configured via server_credentials_default_password

These should be changed immediately after deployment.