Identity and verification

Customer accounts are independent of wp_users. The API foundation includes email/password registration, bearer sessions, one-time challenges, recovery and rate limiting behind an explicit staging flag. The mobile login UI has source-level HTTP integration but cannot store an authentication session until an audited encrypted native vault is available.

Why modular verification

Email challenge validation, templates, expiry, resend rules and transport must live together in one module. WordPress wp_mail() uses the site's chosen mail plugin and SMTP/transport configuration. WhatsApp and SMS are later independent channel modules; no unapproved vendor SDK or platform is required today.

Security boundaries

Use HTTPS, server-side hashing of credentials/tokens, object ownership checks and audited storage. Never store bearer tokens in plaintext localStorage. Verification links/codes are not proof of deliverability until staged email tests succeed. A biometric prompt is only a local unlock convenience and not a customer database.

Cost trade-off

Self-hosting avoids recurring external identity-platform fees but transfers maintenance, incident response, email deliverability and abuse prevention to the project operator. Production launch requires a separate security review.

Identity boundary

A customer login is an HSLG identity, not a WordPress administrator session. The account API registers named HTTPS REST routes for registration, verification, resend, login, recovery, profile and logout. Protected endpoints use bearer-token authorization that resolves the customer ID on the server. Passing a customer ID from the phone never authorizes that account. HSLG business services must repeat authorization checks where they access sensitive records rather than assuming a prior screen or route did it correctly.

Registration, email codes and recoverability

The API verifies JSON shape and input length, enforces rate limits and returns noncommittal responses for registration or recovery attempts. That prevents the application from disclosing which email addresses already exist. Verification challenges need secure random creation, a stored non-reversible representation, expiry, one-time consumption, throttled resend and careful audit handling. A code displayed in a test must not be included in production logs.

The desired implementation is one cohesive email-verification module with handlers, templates, validation and tests. It should call WordPress wp_mail(), allowing the site's installed mail transport to deliver messages. It must not configure global SMTP, hardcode credentials or scatter alternative mail sends across controllers. The present repository still has account repository/controller methods that need consolidation into that module; describing the desired boundary does not imply the refactor is already complete. WhatsApp and other providers are future modules subject to separate policy, cost and consent review.

Mobile credentials and session lifecycle

The server issues a bearer token on successful login and stores an appropriate hash/expiry server-side. The mobile application must put the token in a reviewed Android Keystore / iOS Keychain-backed vault. window.HSLGNativeTokenVault is currently a required contract, not proof that encrypted native persistence exists. If the vault is unavailable, the native login path refuses to claim a completed session. The token should never be written to browser localStorage, embedded in a URL or included in bug-report screenshots.

On restart, rehydrate only through the reviewed vault. On logout, attempt server revocation and clear the local token. If the network is unavailable, local credential clearing must still take place, while UI wording distinguishes local sign-out from confirmed server revocation. Password reset must invalidate outstanding sessions. Repeated token use after revocation must be rejected by the API.

Authorization, transport and attacks

The account controller rejects non-HTTPS requests using is_ssl() and does not simply trust arbitrary client-supplied proxy headers. Virtualmin's reverse-proxy and FPM deployment therefore needs correct trusted TLS state. The API accepts strict Bearer header shape and rate-limits sensitive account actions by operation, email and source address. Logging should retain enough non-secret error category evidence to debug attacks without exposing passwords or active tokens.

Threat cases include brute-force login, account enumeration, code guessing, replayed recovery challenges, token theft, cross-customer profile reads, CSRF confusion with WordPress cookies, malicious QR destinations and duplicate payment calls after timeouts. Each protection must be proved with a test case, not just mentioned in a policy. Public editorial REST endpoints should have different access expectations from protected account/order endpoints.

User experience implications

Customers must understand whether a service is unavailable, a code expired or credentials were invalid. Avoid messages that disclose the existence of a private account. Provide resend cooldown, invalid-code feedback, a reliable password recovery path and a visible sign-out. Social sign-in and biometrics require additional design; they are not substitutes for implementing token storage safely. Staff users must not be able to reset a customer password or impersonate a customer merely because they control a venue admin account.

Evidence required before launch

Run registration, verification, expired challenge, reused challenge, password reset, logout and revoked-token checks against actual HTTPS WordPress/MariaDB staging. Test concurrent requests and rate-limit behaviour. Inspect outbound mail and verify the WordPress mail transport on the deployed host. On a physical Android phone, verify storage survives a normal restart but clears on logout and uninstall, that permissions are correctly scoped and that no token is logged. Record unresolved privacy retention and multi-factor recovery decisions before accepting customer registrations.

Remaining risks and limitations

The native encrypted credential vault and consolidated verification module are not complete. An API that issues tokens before its device storage is safe creates an avoidable credential-theft risk. Mail transport may report send success without inbox delivery; fallback recovery policy is still an owner decision. These are release blockers for live accounts, not merely operational footnotes.