One token — and one accidental second door verifiedimportantWritten by the Hub
/v1 accepts a bearer token from rest_tokens — and also the session cookie of anyone logged into the console.
In detail
The documented road is a token: a row in rest_tokens, created through the console, sent as Authorization: Bearer <token>. The table is empty after installation, so a fresh node has an API that nothing can use, which is a sensible default. www-auth — the console's own account — does not open /v1: HTTP Basic with the console credentials is refused with 401, as is the token passed as a query parameter. The undocumented road is the console's session cookie, which the stand accepted on /v1 endpoints. So the API is not protected by "having a token" but by "having a token *or* being logged into the console", and the console on our stand listens on every interface with a password printed on one of its own screens. The practical reading: closing the console is not optional hardening, it is how the API stays closed. Tokens have enabled and name columns, so they can be revoked without deletion and told apart in the log — www-log-format includes {$authentication}, which makes per-token attribution available without extra work.