# 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](/en/docs/auth-two-factor) can be layered on, because TOTP enrolls against a password credential.

```yaml
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](/en/docs/auth-email-templates), and sign-in is refused until the link is followed.

```yaml
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.

:::callout
**Verification needs SMTP.** With no SMTP configured the app boots with email disabled — the verification message is never sent, and a user who signs up under `requireEmailVerification: true` can never complete sign-in. See [Environment Variables](/en/docs/env-vars).
:::

## 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](/en/docs/user-management).

## Related Pages

- [Strategies Overview](/en/docs/auth-strategies) — the `strategies` array and how to choose.
- [Two-Factor](/en/docs/auth-two-factor) — TOTP on top of this strategy.
- [Email Templates](/en/docs/auth-email-templates) — `verification` and `resetPassword` bodies.
- [Registration Control](/en/docs/auth-registration) — whether the public may sign up at all.
- [Sessions](/en/docs/auth-sessions) — what a successful sign-in issues.