Tokens, OAuth and passkeys

Three kinds of tokens

Hollware stores the SHA-256 of a token, never the token, and shows a new one once. A token is of one site, expires after the days you give it (1 to 365) or never when you give none, and can be revoked from the CLI or the admin; a revoked token stops working on the next request.

A token is worth what its person is worth today: its scopes are intersected with the person's current role on every request.

Passkeys

People sign in with passkeys only. The first owner sets one up with the link that hollware init prints; everyone else with an invitation. Under Account, each person names their passkeys and removes one they lost, never their last; and changes their own name, which nobody else can. The admin is an OAuth client of Hollware itself, and keeps its access token in memory only.

Secrets

A webhook's deliveries are signed with a secret Hollware makes (make_webhook_secret, or Site in the admin), shows once, and keeps in the database sealed with AES-GCM under the Worker secret HOLLWARE_SECRET, so the database alone never holds one in clear. hollware deploy makes HOLLWARE_SECRET when the Worker has none, and never replaces one it has: a new one would leave the sealed secrets unopenable, and the webhooks would need new ones.

Changing the structure of a site takes schema:admin, which only an owner's role grants, whoever holds the token: a person in the admin, or an agent.

Guards

• Host and Origin. Hollware answers only requests for the host of HOLLWARE_PUBLIC_URL. A request from a page of another origin is refused, except reads of the read API from the origins a site lists in cors.origins.
• No cookies on the APIs. /mcp and /v1 read the Authorization header and nothing else. The session cookie of a person is read by the sign-in pages alone.
• No indexing. Every answer carries X-Robots-Tag: noindex, nofollow, and /robots.txt disallows everything: the admin, the APIs and the images are not for search engines. Your sites are.
• Images that cannot run. An SVG is accepted only when nothing in it runs or reaches out, and is served with a policy that runs nothing (see Images).
• Client metadata over the public internet. The OAuth server fetches the metadata documents of clients with global_fetch_strictly_public, so a client cannot point it at your own network.

Activity log

Every change of a site and every refusal is a line of its activity log: who did it, as Hollware verified it (a person in the admin, a personal token, an app a person allowed, or Hollware itself publishing what was scheduled), what the client said about itself (its MCP client and model, shown apart, since it is the client's own claim), the action, what it acted on, and how it ended: done, denied for a missing scope, or failed.

It covers every operation that is not a read, the tokens made and revoked, roles, members removed, invitations made and accepted, sign-in and sign-out, passkeys renamed and removed, names changed, apps allowed and revoked, and scheduled publications. Reads are not logged. The log is append-only in the database: no line is changed, and none is deleted before the retention of its site.

Owners read it in the admin under Activity, filter it by action, person and dates, and download it as CSV. An owner decides what it keeps, under Site, Activity log:

• IP addresses: not kept by default. An address is personal data; if you keep them, Hollware stores only a hash of each address keyed by your site, never the address, so you can tell that requests came from one address without being able to tell which.
• Retention: forever by default, or 30 to 3650 days, after which Hollware deletes the lines.

hollware init and npm create hollware take the same choices as --ip-addresses hashed and --audit-retention-days 365.

Report a vulnerability

Report it privately through the security advisories of the GitHub repository, never in an issue.