AuthServer
Users
Create users and manage credentials.
Users are the people who authenticate through SqlOS. Each user has an email, a display name, and optionally a password.
Dashboard: Auth Server > Users

SDK:
var user = await adminService.CreateUserAsync(
new SqlOSCreateUserRequest(
DisplayName: "Jane Doe",
Email: "jane@acme.com",
Password: "securePassword123"));Admin API:
curl -X POST http://localhost:5062/sqlos/admin/auth/api/users \
-b "$SQLOS_DASHBOARD_COOKIE_JAR" \
-H "Content-Type: application/json" \
-d '{"displayName": "Jane Doe", "email": "jane@acme.com", "password": "securePassword123"}'The Admin API requires an operator session; see Authenticate operator API calls.
| Type | Created by | Has password |
|---|---|---|
| Local | Dashboard, SDK, Email OTP signup, or invitation signup | Optional |
| SSO-provisioned | SAML login with auto-provisioning | No |
| OIDC-linked | Google, Microsoft, GitHub, Apple, or custom social login | No |
Users without a password can sign in through Email OTP, SSO, or OIDC. The current package does not expose a general-purpose dashboard or SDK operation for adding a password to an existing passwordless user. Design onboarding around that passwordless identity, or use the password-reset and account-recovery flows only where their documented eligibility rules apply.
Email OTP signup and invitation signup create users with verified primary email addresses and no password. That is the normal model for passwordless applications.
If your app uses organization onboarding, create an Email Invitation instead of creating a user directly. The invitation acceptance flow verifies the invited email and creates or reactivates the membership transactionally.
SqlOS preserves the supplied address for display and stores a separate trimmed, uppercased lookup key. Use SqlOSAdminService.NormalizeEmail() when you need to query that normalized key directly:
var normalized = SqlOSAdminService.NormalizeEmail("Jane@Acme.COM");
// → "JANE@ACME.COM"