Contrôle de l'inscription

Déclarer une stratégie dit comment quelqu'un s'authentifie. Cela ne dit pas si un inconnu peut créer un compte en premier lieu. auth.allowSignUp est cette seconde décision, indépendante des stratégies activées.

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.

La valeur par défaut est true parce que c'est la bonne réponse pour un produit public. C'est la mauvaise réponse pour la plupart des outils internes et pour tout portail client : là, un compte est quelque chose qu'on vous donne, et laisser l'auto-inscription ouverte signifie que quiconque trouve l'URL n'est qu'à un formulaire d'une session.

Filtrer par invitation

Avec l'auto-inscription fermée, il vous faut malgré tout accueillir de vraies personnes sans qu'un administrateur invente et transmette un mot de passe. Les invitations sont cette voie : un administrateur émet un jeton à usage unique, Sovrium envoie un lien par e-mail, et l'invité définit son propre mot de passe.

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.

Une chaîne de durée s'écrit <entier positif><unité>, l'unité étant s, m, h ou d — 30s, 15m, 72h, 7d. Un nombre nu est lu comme des millisecondes. Toute autre forme échoue à la validation.

Des expirations plus courtes conviennent aux portails clients à haute sécurité ; la valeur 72h par défaut convient à l'intégration B2B, où un invité ne consulte pas forcément ses e-mails le jour même. Les jetons sont à usage unique dans les deux cas, consommés à la première acceptation réussie.

Quel chemin utiliser

Vous voulez	Définissez
Un produit public que chacun peut rejoindre	allowSignUp: true (ou omettez-le).
Une application fermée, utilisateurs accueillis par e-mail	allowSignUp: false + invitations.
Une application fermée, comptes provisionnés par script	allowSignUp: false + POST /api/auth/admin/create-user.
Un accès uniquement fédéré, sans comptes locaux	allowSignUp: false + une stratégie oauth.

Pages connexes

• Invitations — le flux que invitationTokenExpiry configure.
• Gestion des utilisateurs — amorçage administrateur et API create-user.
• Présentation des stratégies — le tableau strategies qui l'accompagne.
• Modèles d'e-mail — le corps de l'e-mail invitation.
• Rôles & RBAC — le rôle que reçoit un utilisateur nouvellement créé.