3 Ways to Design a Password Reset Flow. Most Teams Only Know One.

How each approach works, what it protects against, and when to reach for which one.

Most developers treat password reset as a checkbox. User clicks “Forgot Password”, they get a link, they set a new password. Done. The implementation barely gets a second thought.

Then a user gets locked out because their link expired in ten minutes, or a security researcher finds that your reset tokens are stored in plaintext, or you discover that your “Host” header is being injected into the reset URL you are sending to users. Simple feature. Lots of ways to get it wrong.

There are three distinct ways to design a password reset flow. They have different security properties, different operational tradeoffs, and different contexts where they make sense. This article covers all three, with enough implementation detail to actually build each one.

The shared foundation every approach needs

Before getting into the specific designs, three rules apply to all of them.

Return the same response whether the email exists or not. If your endpoint returns “email not found” for unknown addresses and “reset link sent” for valid ones, you have just built an…