The account layer, finished.

• Passwordless sign-in for customers — a one-time code by email or SMS, or Google Sign-In.
• Password sign-in for administrators, hashed with argon2id.
• Fully configurable methods. Each project decides which identifier (email, phone, username) and which method is available — with no code change.
• Phone numbers stored in international format, so the country-code problems that plague every other implementation simply don't occur.
• Configurable password policy: minimum length, character mix, checks against known-breached password lists, expiry, and reuse prevention.

• TOTP apps and WebAuthn security keys or passkeys.
• Recovery codes for when the second factor isn't to hand.
• Trusted devices — a recognised device isn't challenged repeatedly.
• Step-up authentication before sensitive actions. Even an active session must re-prove itself before changing an email address.
• Session management: the user sees where they're signed in and can end any session individually or all at once.
• Visible sign-in history — successes, failures, and new devices.
• Rate limiting on sensitive routes with persistent blocking for repeat abuse, not just a window that resets.

• User preferences — language, notification settings — stored in one place and read whenever anything is sent.
• Two-step email change: the current address stays active until the new one is confirmed, so a typo can never lock someone out of their own account.

• Roles are data, not code. Define the roles this business actually has, with the exact capabilities each needs.
• Permissions are re-read from the database on every request and never stored in the login token — so revoking access takes effect immediately, not whenever the token happens to expire.
• A separate developer tier sits above the top administrator. Installation-critical settings are reachable only from there, so a client admin cannot break their own installation.

• One account can belong to several organisations, with a different role in each.
• Data is scoped at the authorisation layer rather than by each query remembering to filter — which is what makes multi-vendor marketplaces safe to build.
• Cross-organisation data leakage is an explicit, mandatory test case on every affected endpoint.

• Controlled impersonation: a support operator sees exactly what the customer sees — for a short window, after fresh step-up authentication, and never for sensitive operations like changing a password, email, or 2FA.
• Forced session termination, for responding quickly to a reported account compromise.

Every impersonation and every forced sign-out is recorded with the actor, the timestamp, and whose account it touched. There is no way to use either quietly.