# Registration Control

Declaring a strategy says _how_ someone authenticates. It does not say _whether_ a stranger may create an account in the first place. `auth.allowSignUp` is that second decision, and it is independent of which strategies you enabled.

```yaml
auth:
  allowSignUp: false
  strategies:
    - type: emailAndPassword
```

| Value            | Behavior                                                                                                       |
| ---------------- | -------------------------------------------------------------------------------------------------------------- |
| `true` (default) | Anyone can self-register via the enabled strategies.                                                           |
| `false`          | Self-registration is disabled. Only admins create users via `POST /api/auth/admin/create-user` or invitations. |

The default is `true` because it is the right answer for a public product. It is the wrong answer for most internal tools and every customer portal — in those, an account is something you are _given_, and leaving self-registration on means anyone who finds the URL is one form away from a session.

:::callout
**`allowSignUp: false` closes the public door, not the admin one.** Admin-driven user creation is always available when auth is configured, and it is not affected by this flag. Nor are invitations — see below.
:::

## Gating with Invitations

With self-registration off, you still need a way to onboard real people that does not involve an admin inventing and transmitting a password. Invitations are that path: an admin issues a single-use token, Sovrium emails a link, and the invitee sets their own password.

```yaml
auth:
  allowSignUp: false
  strategies:
    - type: emailAndPassword
  invitationTokenExpiry: 7d
```

| Property                | Description                                                                                                                   |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| `invitationTokenExpiry` | Lifetime of tokens from `POST /api/auth/admin/invite-user`. Duration string (`72h`, `7d`) or milliseconds. Defaults to `72h`. |

A duration string is `<positive integer><unit>` with `unit` one of `s`, `m`, `h`, `d` — `30s`, `15m`, `72h`, `7d`. A bare number is read as milliseconds. Anything else fails validation.

Shorter expiries suit high-security customer portals; the `72h` default suits B2B onboarding, where an invitee may not check email the same day. Tokens are single-use either way, consumed on first successful accept.

## Which Path to Use

| You want                                       | Set                                                                       |
| ---------------------------------------------- | ------------------------------------------------------------------------- |
| A public product anyone can join               | `allowSignUp: true` (or omit it).                                         |
| A closed app, users onboarded by email         | `allowSignUp: false` + [invitations](/en/docs/auth-invitations).          |
| A closed app, accounts provisioned by a script | `allowSignUp: false` + `POST /api/auth/admin/create-user`.                |
| Federated-only access, no local accounts       | `allowSignUp: false` + an [`oauth`](/en/docs/auth-social-oauth) strategy. |

## Related Pages

- [Invitations](/en/docs/auth-invitations) — the flow `invitationTokenExpiry` configures.
- [User Management](/en/docs/user-management) — admin bootstrap and the create-user API.
- [Strategies Overview](/en/docs/auth-strategies) — the `strategies` array this sits beside.
- [Email Templates](/en/docs/auth-email-templates) — the `invitation` email body.
- [Roles & RBAC](/en/docs/auth-roles-rbac) — the role a newly created user receives.