Présentation de l'authentification

Sovrium propose l'authentification comme une capacité de plateforme de premier ordre, propulsée par Better Auth. Un unique bloc auth dans la configuration de votre application active l'inscription, la connexion, les sessions, le contrôle d'accès basé sur les rôles et la gestion administrateur des utilisateurs — aucun code d'authentification à écrire.

Le bloc auth répond à une seule question : cette application a-t-elle des utilisateurs ? Lorsqu'il est présent, l'authentification est activée ; lorsqu'il est omis, chaque route /api/auth/* renvoie 404 et l'application est entièrement publique.

auth:
  strategies:
    - type: emailAndPassword
  defaultRole: member

Cette configuration de quatre lignes vous offre une inscription et une connexion par e-mail/mot de passe fonctionnelles, des sessions gérées côté serveur, les trois rôles intégrés et les points de terminaison de gestion administrateur des utilisateurs.

Activer l'authentification

L'authentification est activée par la présence de l'objet auth. Il n'existe pas de drapeau auth.enabled: true.

État	Résultat
`auth` omis	L'application est publique. Toutes les routes `/api/auth/*` renvoient `404`. Pas d'identité, pas de sessions.
`auth` présent	L'authentification est activée. Les routes d'inscription/connexion sont montées, les sessions sont émises, le RBAC et les fonctions d'administration s'appliquent.

Au minimum, le bloc auth exige un tableau strategies non vide (au moins une stratégie, sans types en double). Tout le reste est optionnel et vient s'ajouter par-dessus.

Les fonctions d'administration sont toujours actives. Lorsque auth est configuré, les points de terminaison de gestion des utilisateurs, d'attribution des rôles et d'usurpation d'identité sont montés automatiquement — il n'y a pas de bascule distincte. Le premier utilisateur à s'inscrire devient administrateur (firstUserAdmin).

Le bloc de configuration `auth`

L'objet auth accepte les propriétés de premier niveau suivantes. Chacune renvoie à sa page dédiée.

Propriété	Description
`strategies`	Obligatoire. Tableau de stratégies d'authentification (e-mail/mot de passe, lien magique, OAuth). Au moins une ; sans types en double. Voir Stratégies.
`allowSignUp`	Booléen. Contrôle l'auto-inscription. `true` (par défaut) permet à quiconque de s'inscrire ; `false` réserve la création d'utilisateurs aux administrateurs. Voir Stratégies.
`roles`	Tableau de définitions de rôles personnalisés ajoutées par-dessus les rôles intégrés. Voir Rôles & RBAC.
`defaultRole`	Rôle attribué aux nouveaux utilisateurs lors de leur inscription. Par défaut `member`. Voir Rôles & RBAC.
`groups`	Groupes d'utilisateurs pour une appartenance plusieurs-à-plusieurs et des permissions à l'échelle d'un groupe. Voir Groupes.
`twoFactor`	Authentification à deux facteurs basée sur TOTP. Nécessite la stratégie `emailAndPassword`. Voir Deux facteurs.
`emailTemplates`	Objet et corps personnalisés pour les e-mails d'authentification (vérification, réinitialisation, lien magique, OTP, invitation, …). Voir Stratégies.
`invitationTokenExpiry`	Durée de vie des jetons d'invitation administrateur à usage unique. Chaîne de durée (`72h`, `7d`) ou millisecondes. Par défaut `72h`.
`scopeTables`	Tables référencées par la table de jonction multi-locataire `user_access`. Pilote le périmètre `$currentUser.assignments`. Voir Sessions.
`landingPath`	Chemin de montage du résolveur de moteur pour l'atterrissage après connexion par rôle. Voir Atterrissage après connexion.
`noAccessPath`	Chemin de repli lorsqu'aucun `defaultLanding` de rôle ne correspond à la session. Par défaut `/403`. Voir Atterrissage après connexion.

Les secrets d'infrastructure (clés de signature, URL de rappel, identifiants OAuth) résident dans les variables d'environnement — pas dans ce schéma. Voir Variables d'environnement.

Rôles par défaut

Chaque application Sovrium dont l'authentification est configurée dispose de trois rôles intégrés, disponibles sans aucune configuration. Ils ne peuvent pas être redéfinis.

Rôle	Niveau	Accès
`admin`	80	Accès complet — gérer les utilisateurs, les rôles, les paramètres ; toutes les permissions de table.
`member`	40	Accès standard aux ressources de l'application (le rôle par défaut des nouveaux utilisateurs).
`viewer`	10	Accès en lecture seule.

Le niveau numérique établit une hiérarchie (plus élevé = plus privilégié) utilisée par la résolution des permissions. Les rôles personnalisés s'insèrent dans cette hiérarchie avec leur propre level. Voir Rôles & RBAC pour les définitions, la hiérarchie et les rôles administrateur.

Variables d'environnement requises

Deux variables d'environnement sont requises pour l'authentification en production :

Variable	Rôle
`AUTH_SECRET`	Clé secrète pour signer les jetons et chiffrer les sessions. Utilisez une chaîne aléatoire forte (32+ caractères).
`BASE_URL`	URL de base de l'application (par ex. `https://myapp.com`). Utilisée pour les URL de rappel d'authentification et les liens d'e-mail.

AUTH_SECRET=your-strong-random-secret-32-chars-min
BASE_URL=https://myapp.com

Ne committez jamais AUTH_SECRET. Traitez-le comme un mot de passe de base de données. Sa rotation invalide toutes les sessions actives. Voir Variables d'environnement pour la liste complète, y compris les paires OAuth {PROVIDER}_CLIENT_ID / {PROVIDER}_CLIENT_SECRET.

Exemple complet

auth:
  # Two ways in: credentials + Google social login
  strategies:
    - type: emailAndPassword
      minPasswordLength: 12
      requireEmailVerification: true
    - type: oauth
      providers: [google, github]

  # Self-registration on, new users start as viewers
  allowSignUp: true
  defaultRole: viewer

  # One extra role beyond the built-ins
  roles:
    - name: editor
      description: Can edit content
      level: 30

  # Group membership for field-level permissions
  groups:
    - name: marketing
    - name: finance

  # TOTP 2FA (requires emailAndPassword above)
  twoFactor:
    issuer: MyApp
    backupCodes: true

Pour aller plus loin

Stratégies — e-mail/mot de passe, lien magique, OTP par e-mail, connexion sociale/OAuth, contrôle de l'inscription et modèles d'e-mail.
Rôles & RBAC — définitions de rôles, hiérarchie et rôles administrateur.
Groupes — appartenance plusieurs-à-plusieurs et permissions basées sur les groupes.
Sessions — configuration des sessions, révocation et sessions à périmètre actif.
Deux facteurs — configuration TOTP et codes de récupération.
Serveur OAuth — Sovrium en tant que serveur d'autorisation OAuth/OIDC.
Atterrissage après connexion — atterrissage par rôle et interpolation $currentUser.assignments.
Permissions de table — comment les rôles et les groupes contrôlent l'accès par table et par champ.

← PreviousTéléversements de fichiers Next →Stratégies