Authentification et jumelage

Session humaine

L’activation passe par POST /api/account/activate avec token et password. Les invitations sont émises par l’opérateur, pas par une inscription publique. GET /api/account indique le compte et mfaRequired ; GET /api/account/verified exige une session vérifiée.

La session Better Auth est transmise par des cookies HttpOnly, SameSite=Lax, Secure en HTTPS de production. Sa durée configurée est de huit heures. Pour les opérations de rôle, une session de moins de quinze minutes est exigée en plus des autres contrôles.

Le client existant configure TOTP puis vérifie le code de connexion. N’implémentez pas la génération de cookies côté client et ne désactivez pas le contrôle d’origine pour une intégration.

Proxy d’authentification autorisé

Le proxy refuse les chemins absents de sa liste autorisée. La génération de nouveaux codes de récupération exige une session MFA vérifiée. Les formats détaillés des opérations Better Auth relèvent du client d’authentification déjà utilisé par l’application ; le contrat OpenAPI téléchargeable couvre les routes Kelna explicites, hors proxy /api/auth/*.

Identité d’appareil

1. Avec une session humaine MFA autorisée, créez un code par POST /api/organizations/{organizationId}/venues/{venueId}/pairing avec kind: tablet ou pass.
2. Sur l’origine de l’application, envoyez POST /api/device/pair avec code et kind. Le code brut contient exactement huit caractères de l’alphabet autorisé ; la normalisation des espaces est faite par l’interface.
3. Conservez le cookie HttpOnly kelna.device reçu. L’autorisation dure au maximum quatre-vingt-dix jours et peut être révoquée.
4. Lisez GET /api/device pour vérifier le contexte. Le passe lit la salle ; seule une tablette autorisée peut écrire.

{
  "kind": "tablet"
}