Authentication and pairing

Human session

Activation uses POST /api/account/activate with token and password. Invitations are issued by the operator, not through public sign-up. GET /api/account reports the account and mfaRequired; GET /api/account/verified requires a verified session.

The Better Auth session uses HttpOnly, SameSite=Lax cookies, with Secure in HTTPS production. Its configured lifetime is eight hours. Role operations require a session less than fifteen minutes old in addition to other checks.

The existing client sets up TOTP and verifies the sign-in code. Do not generate cookies in client code or disable origin checks for an integration.

Allowed authentication proxy

The proxy rejects paths outside its allowlist. Generating new recovery codes requires a verified MFA session. Detailed Better Auth operation formats belong to the authentication client already used by the application; the downloadable OpenAPI contract covers explicit Kelna routes, excluding /api/auth/*.

Device identity

1. Using an authorized human MFA session, create a code through POST /api/organizations/{organizationId}/venues/{venueId}/pairing with kind: tablet or pass.
2. On the application origin, send POST /api/device/pair with code and kind. The raw code contains exactly eight characters from the allowed alphabet; whitespace normalization is performed by the interface.
3. Keep the returned HttpOnly kelna.device cookie. Authorization lasts at most ninety days and may be revoked.
4. Read GET /api/device to check the context. The pass reads the room; only an authorized tablet can write.

{
  "kind": "tablet"
}