Strategies Overview

auth.strategies is a required, non-empty array declaring how users authenticate. Each entry is a discriminated union keyed by type, and no two entries may share the same type — a strategy is configured once or not at all.

app.yaml

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

An app declaring that block accepts credential sign-in and Google/GitHub sign-in. Users arriving by either route land in the same account store, with the same roles and sessions.

`type`	Sign-in feels like…	Configured on
`emailAndPassword`	A password form.	Email & Password
`magicLink`	A one-time link in the inbox.	Magic Link & Email OTP
`oauth`	A "Continue with Google" button.	Social & OAuth Providers

Choosing One

The array is additive: every declared strategy is offered, and one user may hold credentials for several. Pick by what your users already have.

Situation	Declare
Internal tool; staff already have work Google accounts	`oauth` alone — no password to leak, no reset flow to build.
Customer portal with occasional logins	`magicLink` alone — nothing for a customer to forget.
You need two-factor authentication	`emailAndPassword` — 2FA requires it.
Mixed audience, some federated and some not	`emailAndPassword` and `oauth`.

magicLink and the email-OTP flow both send mail. When SMTP is unset the app still boots, but with email disabled and a logged warning — those strategies then fail to deliver silently. See Environment Variables.

Email & Password

Moved to Email & Password.

Magic Link

Moved to Magic Link & Email OTP.

Email-OTP

Moved to Magic Link & Email OTP.

Moved to Social & OAuth Providers.

Registration Control

Moved to Registration Control.

Email Templates

Moved to Email Templates.

Validation

Two rules are enforced when the config is decoded, so sovrium validate catches a malformed block offline:

At least one strategy — an empty array is rejected. Omitting auth entirely is how you run with no authentication at all.
No duplicate type — two emailAndPassword entries would make the effective password policy ambiguous.

A third rule reaches across the block: configuring auth.twoFactor without an emailAndPassword strategy is rejected, because TOTP enrolls on top of a password credential.

Email & Password — password policy, verification, auto sign-in.
Magic Link & Email OTP — the two passwordless flows.
Social & OAuth Providers — the five providers and their credentials.
Registration Control — who is allowed to create an account.
Email Templates — the subject and body of every auth email.
Authentication Overview — the auth block strategies sit inside.

Last updated August 11, 2026

← PreviousOverview Next →Email & Password

Edit this page Report an issue

This documentation was written with AI, so errors or outdated content are possible. Sovrium is in beta. Contributions and corrections are welcome.