John Cardinal
a843bd3132
The LAN/IIS and Linux templates shipped a placeholder secret printed in the manual, and installs that kept it signed logins with a public key; any setting also invited short or reused values (security review F1). The setting is now ignored (one warning at boot if still present): the server generates a key once (48 random bytes) into jwt-signing.key in the data folder (beside the app if there is none; owner-only on Linux) and reuses it, so sign-ins also survive a restart where the server used to make a new key each boot (standalone, Linux desktop). If the file cannot be used, a temporary key is used for that run. Templates and dev launch configs drop the setting; manual updated (key page rewritten, setting steps removed from install pages); changelog line. Checked locally: token forged with the old placeholder 401; key file created and reused after restart (old token 200); auth and 2FA tests pass. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1.7 KiB
Security and JWT web tokens
AyaNova uses JSON Web Tokens (JWT) for authentication.
When a User logs in, the AyaNova server issues them a time limited token signed with the server's own sign-in key. The token is sent with every request the User makes and is verified by the server each time.
Tokens expire 5 days after they are issued, and each User can only have one current token: logging in again replaces the previous one.
(Individual Users can be prevented from logging in or accessing the server by setting them inactive, which takes effect immediately regardless of how many days are left on their current token.)
The sign-in key
The AyaNova server generates its sign-in key automatically the first time it starts and keeps it in a file named jwt-signing.key in the AyaNova data folder. It is used from then on, so Users stay logged in when the server restarts. There is nothing to configure.
Keep the data folder protected like the rest of AyaNova's data: anyone who can read the sign-in key file could create valid tokens.
Signing everyone out
To invalidate every token that has been issued (for example if you suspect a token or the key file was exposed): stop the AyaNova server, delete the jwt-signing.key file from the data folder, and start the server again. A new key is generated and every User will need to log in again.
AYANOVA_JWT_SECRET (no longer used)
Before version 8.3.0 the sign-in key could be set with an AYANOVA_JWT_SECRET configuration setting. That setting is no longer used: if it is still present in config.json, an environment variable or the command line it is ignored, a note is written to the server log, and it can safely be removed.