Password reset flow

The forgot-password path, done properly. Someone types their email, you mail a one-time token that expires fast (15 to 60 minutes is typical), they open it, set a new password, and the token dies on use. Store only a hash of the token, never the token itself, and store the new password only under a real password-hashing function: Argon2id first, with bcrypt, scrypt, or a PBKDF2 configuration that meets your policy as perfectly respectable alternatives.

The security work is mostly in what you do not say. The 'did you forget your password' form must return the same message whether the address exists or not, otherwise it becomes a free account-enumeration API. Rate limit by address and by IP, since the endpoint sends real email on demand and makes a lovely mail bomb.

Gotcha most people miss: a successful reset should invalidate every existing session and refresh token, and any pending reset tokens. The whole point is that an attacker may already be logged in. Also decide up front what a reset does to MFA, because letting an emailed link bypass the second factor quietly downgrades your entire login to 'whoever controls the inbox'.