# E-mail et mot de passe

La stratégie par identifiants : l'utilisateur choisit un mot de passe, celui-ci est validé et haché côté serveur, et une session est émise en cas de correspondance. C'est la seule stratégie sur laquelle l'[authentification à deux facteurs](/fr/docs/auth-two-factor) peut se greffer, car le TOTP s'enrôle sur un identifiant de type mot de passe.

```yaml
auth:
  strategies:
    - type: emailAndPassword
      minPasswordLength: 12
      maxPasswordLength: 128
      requireEmailVerification: true
      autoSignIn: true
```

Chaque propriété est optionnelle — `- type: emailAndPassword` seul constitue une stratégie valide et fonctionnelle.

## Propriétés

| Propriété                  | Description                                                                                                       |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| `minPasswordLength`        | Longueur minimale du mot de passe, 6–128. Par défaut `8`.                                                         |
| `maxPasswordLength`        | Longueur maximale du mot de passe, 8–256. Par défaut `128`.                                                       |
| `requireEmailVerification` | Booléen. Lorsque `true`, les utilisateurs doivent vérifier leur e-mail avant de se connecter. Par défaut `false`. |
| `autoSignIn`               | Booléen. Lorsque `true`, les utilisateurs sont connectés automatiquement après l'inscription. Par défaut `true`.  |

Les deux bornes sont contrôlées à leurs propres extrêmes : `minPasswordLength` est rejeté hors de 6–128, et `maxPasswordLength` hors de 8–256 — une configuration ne peut donc pas exiger un minimum de 4 caractères.

## Vérification avant connexion

Avec `requireEmailVerification: true`, l'inscription crée le compte mais pas de session utilisable. Sovrium envoie un e-mail de vérification rendu à partir du [modèle](/fr/docs/auth-email-templates) `verification`, et la connexion est refusée tant que le lien n'a pas été suivi.

```yaml
auth:
  strategies:
    - type: emailAndPassword
      requireEmailVerification: true
  emailTemplates:
    verification:
      subject: Confirm your email for MyApp
      text: 'Hi $name, confirm your email: $url'
```

C'est le réglage qui sépare « quiconque possède une boîte e-mail » de « quiconque sait taper une adresse ». Activez-le pour une inscription publique ; il importe moins lorsque les comptes sont créés par un administrateur, qui peut marquer l'adresse comme vérifiée dès la création.

:::callout
**La vérification nécessite SMTP.** Sans SMTP configuré, l'application démarre avec l'e-mail désactivé — le message de vérification n'est jamais envoyé, et un utilisateur inscrit sous `requireEmailVerification: true` ne pourra jamais terminer sa connexion. Voir [Variables d'environnement](/fr/docs/env-vars).
:::

## Connexion automatique

`autoSignIn` vaut `true` par défaut : une inscription réussie émet immédiatement une session, si bien que l'utilisateur ne ressaisit jamais le mot de passe qu'il vient de choisir. Le passer à `false` le renvoie au formulaire de connexion — utile lorsque l'inscription est un acte privilégié que vous voulez ré-authentifier, et de fait inévitable lorsque `requireEmailVerification` est actif, puisqu'il n'y a encore rien où se connecter.

## Réinitialisation du mot de passe

La réinitialisation est fournie avec la stratégie ; il n'y a rien à activer. Une demande envoie par e-mail un lien à usage unique rendu à partir du modèle `resetPassword`, et un administrateur peut aussi définir un mot de passe directement via `POST /api/auth/admin/set-user-password` — voir [Gestion des utilisateurs](/fr/docs/user-management).

## Pages connexes

- [Présentation des stratégies](/fr/docs/auth-strategies) — le tableau `strategies` et comment choisir.
- [Deux facteurs](/fr/docs/auth-two-factor) — le TOTP par-dessus cette stratégie.
- [Modèles d'e-mail](/fr/docs/auth-email-templates) — les corps `verification` et `resetPassword`.
- [Contrôle de l'inscription](/fr/docs/auth-registration) — si le public peut s'inscrire.
- [Sessions](/fr/docs/auth-sessions) — ce qu'émet une connexion réussie.