Skip to main content
Voir en Markdown

Présentation des stratégies

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, et deux entrées ne peuvent jamais partager le même type — une stratégie se configure une fois, ou pas du tout.

app.yaml
auth:
  strategies:
    - type: emailAndPassword
    - type: oauth
      providers: [google, github]

Une application déclarant ce bloc accepte la connexion par identifiants et la connexion Google/GitHub. Les utilisateurs arrivant par l'une ou l'autre voie atterrissent dans le même magasin de comptes, avec les mêmes rôles et les mêmes sessions.

type La connexion ressemble à… Configuré sur
emailAndPassword Un formulaire de mot de passe. E-mail et mot de passe
magicLink Un lien à usage unique dans la boîte. Lien magique et OTP
oauth Un bouton « Continuer avec Google ». Fournisseurs sociaux et OAuth

Choisir une stratégie

Le tableau est additif : chaque stratégie déclarée est proposée, et un même utilisateur peut détenir des identifiants pour plusieurs. Choisissez selon ce que vos utilisateurs possèdent déjà.

Situation Déclarez
Outil interne ; le personnel a déjà des comptes Google pro oauth seul — aucun mot de passe à fuiter, aucun flux de réinitialisation à construire.
Portail client avec des connexions occasionnelles magicLink seul — rien qu'un client puisse oublier.
Vous avez besoin de l'authentification à deux facteurs emailAndPassword — la 2FA l'exige.
Public mixte, une partie fédérée et l'autre non emailAndPassword et oauth.

magicLink et le flux d'OTP par e-mail envoient tous deux du courrier. Lorsque SMTP n'est pas défini, l'application démarre malgré tout, mais avec l'e-mail désactivé et un avertissement consigné — ces stratégies échouent alors silencieusement à délivrer. Voir Variables d'environnement.

E-mail & mot de passe

Déplacé vers E-mail et mot de passe.

Lien magique

Déplacé vers Lien magique et OTP.

OTP par e-mail

Déplacé vers Lien magique et OTP.

Fournisseurs sociaux / OAuth

Déplacé vers Fournisseurs sociaux et OAuth.

Contrôle de l'inscription

Déplacé vers Contrôle de l'inscription.

Modèles d'e-mail

Déplacé vers Modèles d'e-mail.

Validation

Deux règles sont appliquées au décodage de la configuration : sovrium validate attrape donc un bloc mal formé hors ligne.

  • Au moins une stratégie — un tableau vide est rejeté. Omettre auth entièrement est la façon de fonctionner sans aucune authentification.
  • Aucun type en double — deux entrées emailAndPassword rendraient la politique de mot de passe effective ambiguë.

Une troisième règle traverse le bloc : configurer auth.twoFactor sans stratégie emailAndPassword est rejeté, car le TOTP s'enrôle par-dessus un identifiant de type mot de passe.

Pages connexes

Dernière mise à jour 11 août 2026

Cette documentation a été rédigée avec de l'IA : des erreurs ou du contenu obsolète sont donc possibles. Sovrium est en bêta. Les contributions et corrections sont les bienvenues.

Construit avec Sovrium