# Présentation de l'authentification Sovrium propose l'authentification comme une capacité de plateforme de premier ordre, propulsée par [Better Auth](https://better-auth.com). 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. ```yaml 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. :::callout **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](/fr/docs/auth-strategies). | | `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](/fr/docs/auth-strategies). | | `roles` | Tableau de définitions de rôles personnalisés ajoutées par-dessus les rôles intégrés. Voir [Rôles & RBAC](/fr/docs/auth-roles-rbac). | | `defaultRole` | Rôle attribué aux nouveaux utilisateurs lors de leur inscription. Par défaut `member`. Voir [Rôles & RBAC](/fr/docs/auth-roles-rbac). | | `groups` | Groupes d'utilisateurs pour une appartenance plusieurs-à-plusieurs et des permissions à l'échelle d'un groupe. Voir [Groupes](/fr/docs/auth-groups). | | `twoFactor` | Authentification à deux facteurs basée sur TOTP. Nécessite la stratégie `emailAndPassword`. Voir [Deux facteurs](/fr/docs/auth-two-factor). | | `emailTemplates` | Objet et corps personnalisés pour les e-mails d'authentification (vérification, réinitialisation, lien magique, OTP, invitation, …). Voir [Stratégies](/fr/docs/auth-strategies). | | `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](/fr/docs/auth-sessions). | | `landingPath` | Chemin de montage du résolveur de moteur pour l'atterrissage après connexion par rôle. Voir [Atterrissage après connexion](/fr/docs/auth-post-login). | | `noAccessPath` | Chemin de repli lorsqu'aucun `defaultLanding` de rôle ne correspond à la session. Par défaut `/403`. Voir [Atterrissage après connexion](/fr/docs/auth-post-login). | 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](/fr/docs/env-vars). ## 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](/fr/docs/auth-roles-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. | ```bash AUTH_SECRET=your-strong-random-secret-32-chars-min BASE_URL=https://myapp.com ``` :::callout **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](/fr/docs/env-vars) pour la liste complète, y compris les paires OAuth `{PROVIDER}_CLIENT_ID` / `{PROVIDER}_CLIENT_SECRET`. ::: ## Exemple complet ```yaml 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](/fr/docs/auth-strategies) — 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](/fr/docs/auth-roles-rbac) — définitions de rôles, hiérarchie et rôles administrateur. - [Groupes](/fr/docs/auth-groups) — appartenance plusieurs-à-plusieurs et permissions basées sur les groupes. - [Sessions](/fr/docs/auth-sessions) — configuration des sessions, révocation et sessions à périmètre actif. - [Deux facteurs](/fr/docs/auth-two-factor) — configuration TOTP et codes de récupération. - [Serveur OAuth](/fr/docs/auth-oauth-server) — Sovrium en tant que serveur d'autorisation OAuth/OIDC. - [Atterrissage après connexion](/fr/docs/auth-post-login) — atterrissage par rôle et interpolation `$currentUser.assignments`. - [Permissions de table](/fr/docs/table-permissions) — comment les rôles et les groupes contrôlent l'accès par table et par champ.