Email & Password

The credential strategy: a user picks a password, it is validated and hashed server-side, and a session is issued on a successful match. It is the only strategy two-factor authentication can be layered on, because TOTP enrolls against a password credential.

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

Every property is optional — - type: emailAndPassword on its own is a valid, working strategy.

Properties

Property	Description
minPasswordLength	Minimum password length, 6–128. Defaults to 8.
maxPasswordLength	Maximum password length, 8–256. Defaults to 128.
requireEmailVerification	Boolean. When true, users must verify their email before sign-in. Defaults to false.
autoSignIn	Boolean. When true, users are signed in automatically after sign-up. Defaults to true.

Both length bounds are enforced at their own extremes: minPasswordLength is rejected outside 6–128, and maxPasswordLength outside 8–256, so a config cannot ask for a 4-character minimum.

Verification Before Sign-In

With requireEmailVerification: true, signing up creates the account but not a usable session. Sovrium sends a verification email rendered from the verification template, and sign-in is refused until the link is followed.

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

This is the setting that separates "anyone with an email box" from "anyone who can type an address". Turn it on for public sign-up; it matters less when accounts are created by an admin, who can mark the address verified at creation.

Auto Sign-In

autoSignIn defaults to true: a successful sign-up issues a session immediately, so the user never types the password they just chose. Setting it to false returns them to the sign-in form instead — worth doing when sign-up is a privileged act you want re-authenticated, and unavoidable in practice when requireEmailVerification is on, since there is nothing to sign into yet.

Password Reset

Password reset ships with the strategy; there is nothing to enable. A reset request emails a single-use link rendered from the resetPassword template, and an admin can also set a password directly with POST /api/auth/admin/set-user-password — see User Management.

Related Pages

• Strategies Overview — the strategies array and how to choose.
• Two-Factor — TOTP on top of this strategy.
• Email Templates — verification and resetPassword bodies.
• Registration Control — whether the public may sign up at all.
• Sessions — what a successful sign-in issues.