The Signup card under Application → Authentication controls how new users can create accounts. By default signup is enabled with no restrictions; tightening it usually means picking who can sign up (email domains), how (CAPTCHA, terms), and what they get (default roles, auto-approval).
Master switch. When off, the only way to create users is invitations or the Management API.
Allowed email domains
Comma-separated list. Only addresses ending in one of these can sign up. Empty = any domain.
Blocked email domains
Comma-separated list. Addresses ending in any of these are rejected.
Block free email providers
Reject Gmail, Yahoo, Hotmail, etc. — useful for B2B products that only want work emails.
Require terms acceptance
Force users to tick a Terms-of-Service checkbox. Pair with termsLink.
Terms link
URL the checkbox label points to.
Require CAPTCHA
Use Cloudflare Turnstile on the signup form. Reduces bot signups.
Auto-approve
When true, accounts are usable immediately. When false, accounts go to "pending approval" and an admin must activate them.
Auto-create tenant
Multi-tenant only. When true, every signup spins up a fresh tenant for that user.
Default roles
Role IDs assigned to new accounts on signup. Most apps want ["role_user"] or similar.
Max signups per day
Hard cap on signups per 24-hour window. Prevents abuse spikes. null = unlimited.
Custom fields
Extra fields collected on the Universal Login signup form, beyond email + password. Stored on the user's metadata and surfaced in the Users tab. See below.
Field types supported: text, email, number, select, checkbox, date, url. Each field is rendered on the Universal Login signup form in the order keys appear, and the answers are written to the user's metadata object — readable later via GET /api/v1/users/{id} or as the user_metadata claim on access tokens that include the profile scope.
Custom fields are validated server-side: required fields can't be skipped, max-length is enforced, select options are constrained to the allowed list. The Universal Login form auto-disables submit until valid.
If your app needs every signup to be associated with a specific tenant up front (rather than letting the user pick or auto-creating one), set requireTenantHint: true on the Authentication Settings page. The OAuth authorize URL must then include tenant_id=..., and Authaz scopes the entire signup flow — Universal Login UI, provider routing, default roles — to that tenant.
This pairs naturally with subdomain-per-tenant setups: acme.yourapp.com always passes tenant_id=tenant_acme to the authorize endpoint, and the user is signed up directly into Acme without ever seeing a picker.
Pending accounts show up in the Users tab with a "Pending approval" badge. Activate them via User detail → Activate or POST /api/v1/users/{id}/activate.
In multi-tenant apps where each tenant has its own login surface, you can override signup rules per tenant. Useful when one tenant wants stricter domain rules than the rest:
