Files
keeporg/docs/PROTOCOL.md
T
root a9308a3e89 Merge concurrent saves on the server, with vaults created from the web
Why: the point of a sync server is that two people can work at once. Picking
a winner was all this one could do while it could not read a vault.

What, end to end:
- A vault is created at /web or with `keeporg vault -create`: the server
  builds an empty KDBX 4 file, encrypts it with the password from the form,
  and stores it as version 1. An existing database can adopt a stored key
  with `keeporg db -id <id> -store-password`, which is verified against the
  stored file before it is accepted.
- A stale push to a `merge` vault is no longer refused. The server opens the
  stored version and the pushed one in memory, folds them together, and
  stores the re-encrypted result. Clients push as usual and pull what comes
  back. Any failure answers 409 merge_failed and the client keeps its copy
  aside, so a failed merge still loses nothing.
- At rest: vault contents stay KDBX-encrypted as always. A merge vault's
  password is kept AES-256-GCM-wrapped under a master key that lives outside
  the data directory, bound to the vault id, never returned by the API. A
  stolen data directory is ciphertext; a stolen data directory plus the
  master key is not. The server runs without a master key and simply refuses
  to create or merge vaults.

This moves the server inside the trust boundary for vaults it can merge,
which is inherent to merging and is stated plainly in the README, the
handover notes and the web form itself. Key-less strategies are unchanged and
remain the default for a database created without a password.

Proved: two clients editing the same version are merged rather than refused,
the newer edit of one entry wins, a merge failure leaves the stored vault
untouched, `merge` is refused without a stored key, the wrapped key never
appears in state.json or the API, and the web interface rejects a form
without its CSRF token, withholds its cookie over plain http, and only offers
groups the user administers. Checked by hand against the real thing: a vault
created in a browser, edited by keepassxc-cli on two sides from the same
version, merged by the server, and both entries read back out with
keepassxc-cli. make check, make test-race, android lint and both .deb builds
are clean.
2026-10-29 17:34:47 +01:00

6.7 KiB
Raw Blame History

KeepOrg HTTP API

Every /api/ endpoint takes and returns JSON and needs Authorization: Bearer <token>, except the login, device and invite endpoints. Errors carry {"code": "...", "error": "..."}; code is stable and meant to be matched on, error is for humans.

HTML is served at /web (sign in, list vaults, create one) and at /device, /invite/{token} and /oidc/callback. The web pages use the same session tokens in a cookie that is HttpOnly, SameSite=Strict and Secure behind https, and every form carries a per-session CSRF token.

Authentication

Method Path Body Answer
POST /api/v1/auth/login {username, password, totp, label} {token, expires_at, user}; 401 totp_required when a second factor is enrolled and missing, 401 totp_invalid, 401 bad_credentials
POST /api/v1/auth/logout – revokes the calling token
GET /api/v1/auth/whoami – the account and its group memberships
POST /api/v1/auth/totp/enroll – {secret, uri}; not active until confirmed
POST /api/v1/auth/totp/confirm {code} {totp_enabled: true}
POST /api/v1/auth/device/start {label} {device_code, user_code, verification_url, interval, expires_in}
POST /api/v1/auth/device/poll {device_code} 202 {status: "pending"}, then 200 {token, ...} once; 410 expired

A device code is single use: the first successful poll consumes it.

Synchronization

Method Path Notes
GET /api/v1/databases {databases: [{id, name, perm, merge_strategy, version, sha256, size, updated_at, updated_by}]}
GET /api/v1/databases/{id}/blob bytes; ETag: "<version>", X-KeepOrg-SHA256; 204 when the database has no content yet; ?version=<n> reads a stored older version
PUT /api/v1/databases/{id}/blob body is the KDBX file. If-Match is required
GET /api/v1/events SSE. Accepts ?access_token= because an event stream cannot always set headers

PUT semantics

If-Match carries the version the edit was based on, or * to force.

Condition Status Body
If-Match missing 428 precondition_required –
version matches, bytes differ 200 {version, sha256, unchanged: false}
version matches, bytes identical 200 {version, sha256, unchanged: true}
version stale, strategy is merge 200 {version, sha256, merged: true, merge_summary, based_on} — the two copies were folded together and the result stored as a new version
version stale, strategy is merge, but merging failed 409 merge_failed {error, current_version, merge_strategy}; the stored vault is untouched
version stale, any other strategy 409 conflict {current_version, merge_strategy}, plus ETag and X-KeepOrg-Strategy
If-Match: *, strategy is client-wins 200 the server copy is replaced
If-Match: *, any other strategy 409 force_not_allowed –
read-only access 403 forbidden –
no access 404 not_found a database you cannot read does not exist to you
larger than max_db_size_mb 413 too_large –

X-KeepOrg-SHA256 on a PUT is optional; when present it must match the body or the request is rejected with 400 checksum_mismatch.

After any accepted push, compare the sha256 in the answer with what you sent. If they differ the server stored something else — a merge — and the local copy must be replaced by a fresh GET.

Events

event: db-updated
data: {"type":"db-updated","database_id":"...","name":"Team","version":7,"sha256":"...","by":"alice"}

event: db-list-changed
data: {"type":"db-list-changed","database_id":"..."}

db-updated follows an accepted push; db-list-changed follows a grant, rename, strategy change or deletion. A comment line (: keepalive) arrives every 25 seconds. Reconnect on any error and reconcile fully; events are notifications, never state.

Vaults

A vault is a database the server created and can open. Creating one is the only way the server comes to hold a KDBX key, and the only strategy that needs one is merge.

Method Path Body Needs
POST /api/v1/vaults {name, owner_group_id, merge_strategy, password} group admin of the owner
POST /api/v1/databases/{id}/key {password} or {forget: true} database admin

POST /api/v1/vaults builds an empty KDBX 4 database, encrypts it with password, stores it as version 1 and answers with the database view. The password must be at least 12 characters. For merge_strategy: "merge" (the default here) the password is kept, encrypted under the server's master key; for every other strategy it is used once and forgotten. A server with no master key refuses with 400.

POST /api/v1/databases/{id}/key stores the password of a database that already has content, after checking that it opens the stored version, which is how an uploaded database becomes mergeable. {"forget": true} removes it; that is refused while the strategy is still merge.

The wrapped key is never returned by any endpoint.

Administration

Permission needed is in the last column. "Group admin" means administering the group named or any group above it.

Method Path Body / query Needs
GET /api/v1/groups – any account; lists what you can see
POST /api/v1/groups {name, parent_id} group admin of the parent; server admin for a root group
DELETE /api/v1/groups/{id} – group admin; refuses while it has children, members or databases
POST /api/v1/groups/{id}/members {username or user_id, role} group admin
DELETE /api/v1/groups/{id}/members/{user} – group admin
POST /api/v1/databases {name, owner_group_id, merge_strategy} group admin of the owner
PATCH /api/v1/databases/{id} {name?, merge_strategy?} database admin
DELETE /api/v1/databases/{id} – database admin; deletes every stored version
POST /api/v1/grants {group_id, database_id, perm} database admin
DELETE /api/v1/grants ?group_id=&database_id= database admin
POST /api/v1/invites {group_id, role, ttl_hours, max_uses} group admin
GET /api/v1/invites – your own invites, and those of groups you administer
GET /api/v1/users – yourself, plus members of groups you administer
GET /healthz – unauthenticated liveness

merge_strategy is one of merge, server-wins, client-wins, manual. Switching to merge requires a stored key and is otherwise refused with 400. perm is one of read, write, admin. role is member or admin.