Password Reset
Applications usually link users to DarkAuth’s hosted password reset flow rather than implementing reset screens themselves. The hosted flow avoids account enumeration, uses hashed single-use tokens, and replaces the OPAQUE record correctly.
Self-service reset
Section titled “Self-service reset”The public reset request endpoint accepts an email address and returns a generic response. If reset is enabled, SMTP works, and policy allows it, DarkAuth sends a reset link. The user opens the link and completes a new OPAQUE setup.
Applications should not build their own “does this email exist?” behavior around reset. That defeats the privacy goal of the hosted flow.
Admin-triggered reset
Section titled “Admin-triggered reset”Admins can send a reset email from the user detail page or through the admin API. The admin never sees the plaintext reset token. The action is audited.
Session invalidation
Section titled “Session invalidation”A successful reset consumes the token, replaces the OPAQUE record, clears password-reset-required state, consumes other reset tokens for the user, and deletes active sessions, authorization codes, and pending authorization requests.
Applications should expect users to sign in again after reset.
ZK recovery boundary
Section titled “ZK recovery boundary”Resetting the password restores account access. It does not automatically recover encrypted application data that depended on old password-derived material. If your app uses DRK-protected data, document your recovery flow and explain what happens when the old password is unavailable.