# Stratégies d'authentification `auth.strategies` est un **tableau obligatoire et non vide** déclarant comment les utilisateurs s'authentifient. Chaque entrée est une union discriminée indexée par `type`. Au moins une stratégie est requise, et **deux entrées ne peuvent jamais partager le même `type`**. ```yaml auth: strategies: - type: emailAndPassword - type: oauth providers: [google, github] ``` | `type` | Description | | ------------------ | -------------------------------------------------------------------------------- | | `emailAndPassword` | Inscription et connexion traditionnelles par identifiants. | | `magicLink` | Connexion sans mot de passe via un lien e-mail à usage unique. | | `oauth` | Connexion sociale avec des fournisseurs d'identité externes (Google, GitHub, …). | :::callout **L'OTP par e-mail s'active différemment.** Il n'existe pas de stratégie `type: emailOtp`. L'OTP par e-mail s'active automatiquement lorsque vous fournissez un modèle `auth.emailTemplates.emailOtp` (voir [OTP par e-mail](#email-otp) ci-dessous). ::: ## E-mail & mot de passe La stratégie la plus courante. Les identifiants sont validés côté serveur et une session est émise en cas de succès. ```yaml auth: strategies: - type: emailAndPassword minPasswordLength: 12 maxPasswordLength: 128 requireEmailVerification: true autoSignIn: true ``` | 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`. | Lorsque `requireEmailVerification: true`, un e-mail de vérification est envoyé à l'inscription à l'aide du modèle `verification` (voir [Modèles d'e-mail](#email-templates)). ## Lien magique Authentification sans mot de passe. L'utilisateur saisit son e-mail, reçoit un lien à usage unique, et se connecte en cliquant dessus. Nécessite la configuration de SMTP (voir [Variables d'environnement](/fr/docs/env-vars)). ```yaml auth: strategies: - type: magicLink expirationMinutes: 30 ``` | Propriété | Description | | ------------------- | ------------------------------------------------------------------ | | `expirationMinutes` | Durée de vie du lien en minutes (entier positif). Par défaut `15`. | Le corps du lien est rendu à partir du modèle d'e-mail `magicLink` lorsqu'il est fourni. ## OTP par e-mail L'OTP par e-mail délivre un code numérique à usage unique par e-mail au lieu d'un lien. **Ce n'est pas une entrée de stratégie** — il s'active lorsque vous définissez le modèle d'e-mail `emailOtp` : ```yaml auth: strategies: - type: emailAndPassword emailTemplates: emailOtp: subject: Your sign-in code text: 'Your verification code is $code. It expires shortly.' ``` La présence de `emailTemplates.emailOtp` monte le plugin d'OTP par e-mail. La variable `$code` est remplacée par le code à usage unique généré. ## Fournisseurs sociaux / OAuth Connexion fédérée via des fournisseurs d'identité externes. Les identifiants ne sont **jamais** dans le schéma — ils sont chargés depuis les variables d'environnement. ```yaml auth: strategies: - type: oauth providers: [google, github, microsoft, slack, gitlab] ``` | Propriété | Description | | ----------- | ----------------------------------------------------------------------------------------------------------- | | `providers` | Tableau non vide d'identifiants de fournisseurs. Identifiants chargés depuis les variables d'environnement. | Fournisseurs pris en charge : | Fournisseur | Cas d'usage | | ----------- | ---------------------------------- | | `google` | Intégration Google Workspace. | | `github` | Authentification des développeurs. | | `microsoft` | Entreprise / Azure AD. | | `slack` | Communication d'espace de travail. | | `gitlab` | Intégration développeur / CI-CD. | Chaque fournisseur activé nécessite une paire d'identifiants dans l'environnement : ```bash GOOGLE_CLIENT_ID=your-client-id GOOGLE_CLIENT_SECRET=your-client-secret GITHUB_CLIENT_ID=your-client-id GITHUB_CLIENT_SECRET=your-client-secret ``` La forme générale est `{PROVIDER}_CLIENT_ID` et `{PROVIDER}_CLIENT_SECRET`. Les URL de rappel sont dérivées de `BASE_URL`. Voir [Variables d'environnement](/fr/docs/env-vars). ## Contrôle de l'inscription `auth.allowSignUp` détermine si le public peut créer ses propres comptes. ```yaml auth: allowSignUp: false strategies: - type: emailAndPassword ``` | Valeur | Comportement | | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | `true` (par défaut) | Quiconque peut s'auto-inscrire via les stratégies activées. | | `false` | L'auto-inscription est désactivée. Seuls les administrateurs créent des utilisateurs via `POST /api/auth/admin/create-user` ou des invitations. | Lorsque l'auto-inscription est désactivée, les administrateurs intègrent les utilisateurs avec des jetons d'invitation à usage unique : ```yaml auth: allowSignUp: false strategies: - type: emailAndPassword invitationTokenExpiry: 7d ``` | Propriété | Description | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | `invitationTokenExpiry` | Durée de vie des jetons issus de `POST /api/auth/admin/invite-user`. Chaîne de durée (`72h`, `7d`) ou millisecondes. Par défaut `72h`. | :::callout Des expirations plus courtes conviennent aux portails clients à haute sécurité ; la valeur par défaut `72h` convient à l'intégration B2B où les invités ne consultent pas forcément leur e-mail immédiatement. Les jetons d'invitation sont à usage unique et consommés lors de la première acceptation réussie. ::: ## Modèles d'e-mail `auth.emailTemplates` personnalise l'objet et le corps des e-mails d'authentification. Chaque modèle est optionnel — Better Auth fournit des valeurs par défaut judicieuses. Définir le modèle `emailOtp` **active** en outre le flux d'OTP par e-mail. ```yaml auth: strategies: - type: emailAndPassword - type: magicLink emailTemplates: verification: subject: Verify your email for MyApp text: 'Hi $name, confirm your email: $url' resetPassword: subject: Reset your password text: 'Reset your password: $url' html: '

Click here to reset your password.

' magicLink: subject: Your sign-in link text: 'Sign in to MyApp: $url' ``` | Modèle | Quand il est envoyé | | ---------------------- | ----------------------------------------------------------------------- | | `verification` | Vérification de l'e-mail après l'inscription. | | `resetPassword` | Demande de réinitialisation du mot de passe. | | `magicLink` | Connexion par lien magique. | | `emailOtp` | Code e-mail à usage unique (sa présence active l'OTP par e-mail). | | `twoFactorBackupCodes` | Envoi des codes de secours à deux facteurs. | | `welcome` | E-mail de bienvenue après la vérification. | | `accountDeletion` | Confirmation de suppression de compte. | | `invitation` | Invitation émise par un administrateur (intégration sans mot de passe). | Chaque modèle accepte un `subject` obligatoire et des corps `text` et/ou `html` optionnels. Les corps prennent en charge la substitution `$variable` : | Variable | Signification | | ------------------- | ------------------------------------------------------------------------------------------ | | `$url` | Lien d'action (vérifier, réinitialiser, lien magique, accepter une invitation). | | `$name` | Nom du destinataire. | | `$email` | Adresse e-mail du destinataire. | | `$code` | Code à usage unique (OTP par e-mail). | | `$organizationName` | Nom de l'organisation (invitations). | | `$inviterName` | Nom de l'administrateur qui a envoyé l'invitation (invitations administrateur uniquement). | :::callout Les e-mails de lien magique, d'OTP par e-mail, de réinitialisation du mot de passe et de vérification nécessitent tous SMTP. Lorsque SMTP n'est pas défini, l'application démarre avec l'e-mail désactivé et consigne un avertissement — ces stratégies ne pourront pas délivrer leurs messages. Voir [Variables d'environnement](/fr/docs/env-vars). ::: ## Pages associées - [Présentation de l'authentification](/fr/docs/auth-overview) — le bloc `auth` et la place des stratégies. - [Sessions](/fr/docs/auth-sessions) — ce qui se passe après une connexion réussie. - [Deux facteurs](/fr/docs/auth-two-factor) — ajouter le TOTP par-dessus l'e-mail/mot de passe. - [Variables d'environnement](/fr/docs/env-vars) — `AUTH_SECRET`, `BASE_URL` et identifiants OAuth.