Authentication

Sign-in is a magic link. You request one, it arrives by email, and redeeming it returns a session. The first redemption for an unknown address creates the user, the tenant and the first API key in one step, which is why sign-up and sign-in are the same route.

The reasoning is unglamorous: passwords get reused, leaked and phished, and a single-use link removes the whole category. There is nothing to rotate and nothing to store.

A browser session is a short-lived access token backed by an HttpOnly refresh cookie. An API key is a long-lived token intended for a server, carrying an explicit scope set.

Both are presented the same way, as a bearer token, and both are verified on the same path. A route does not care which kind of credential it received, only whether that credential carries the required scope.

A key should carry the smallest scope set that lets its holder do its job. A key that can only read datasets is a bounded problem if it leaks; one that can create deployments and read billing is not.

Administrative actions — changing billing, deleting a tenant — are deliberately unavailable to any API key. They require an interactive session, which means a leaked key cannot be used to do them under any circumstances.

Creating a key returns its secret exactly once. There is no route that reveals it again, because storing it in a form we could return would mean storing it in a form an attacker could read.

Keys can be listed with their scopes and last-use timestamps, which is enough to identify one that is no longer needed without knowing its value. Revocation is immediate.