To add password reset to an app you need a link that expires and dies after one use.
To add password reset to an app you need four pieces: a screen that takes an email address, a server that mints a random token and stores only its hash, an email that carries that token in a link, and a screen that takes the new password. The phone app is the two screens. Everything that makes the forgot password flow safe happens on the server, which is why this job lands on your plate straight after adding user login.
The limit worth knowing before you start: you cannot build this in the app alone. You need somewhere to keep the token and something that actually delivers email, and both cost either money or a weekend. This page covers the flow in order, how long the link should live, what to do when the email does not arrive, and what to accept as the new password.
Try the expiry windowThe short version
A reset does not check who somebody is, it checks that they can read the inbox.
Every design decision in a password recovery app follows from one fact. The flow never verifies a person. It verifies that whoever asked can open the mailbox or the phone the account was registered with. So the link you send is a temporary credential, and it needs the same care as a password: random, short lived, used once, stored hashed.
It also means the account is only as strong as that mailbox. If somebody else can read the inbox, they own the account, and no amount of work inside the app changes that.
The flow, in the order it has to happen
Six steps, and the order is the security. One, the user types an email address. Two, the server answers with the same message whether or not the account exists, in roughly the same amount of time. Three, if the account is real, generate a token from a cryptographically secure random source, store a hash of it against that user with an expiry, and never keep the token itself. Four, send the email with the token in the link. Five, the user opens it, the server checks the hash and the expiry, and the user types the new password twice. Six, delete the token, email the user to say the password changed, and end the other sessions.
Step two is the one most homemade flows get wrong. A screen that says no account with that email is a free membership checker for anyone holding a list of addresses. OWASP puts a consistent message at the top of its guidance and asks for a consistent response time as well, because a fast exit on the missing account branch leaks the same answer through timing even when the wording matches.
Two more rules come from the same page. Rate limit requests per account, or somebody floods a real user's inbox with thousands of reset emails. And do not lock the account when a reset is requested, because that turns a forgotten password form into a way to shut out anybody whose address you know. Nothing about the account should change until a valid token comes back.
None of this is specific to phones. It is the same set of rules you apply to app authentication anywhere, and if you are using a hosted auth provider, most of it is already written and tested for you. That is a real argument for not building it yourself.
How long the reset link should live
There is no single number that a standard hands you for a consumer app, and anybody who quotes one as the rule is guessing. OWASP says the token must be single use and must expire after an appropriate period, and deliberately declines to name a figure.
The closest thing to a published ceiling comes from NIST. In SP 800-63B, an issued recovery code, which is what a reset link or reset code is, shall be valid for at most 24 hours when it is sent to an email address, and at most 10 minutes when it is sent by text message or voice. Those rules are written for federal identity systems and not for your app, so read them as an upper bound rather than a target.
Inside that ceiling the trade is plain. A longer window leaves the link sitting readable in a mailbox that may be shared, synced to a laptop, or breached next year. A shorter window sends more people back to the form because they read their mail in the evening. We would land between 15 minutes and an hour for a consumer app, and that is a judgement rather than a rule. What matters far more than the exact number is that the token is deleted the instant it is used, and that asking for a new one kills the old one.
Store the token the way you store a password. Hashed, never in plain text, never in a log line, never in an analytics event, because a reset token in a log is a standing key to the account. If that is new, the wider set of habits sits in app security basics.
NIST SP 800-63B, account recovery and issued recovery codes
How long should the reset link live
The expiry is how long a stolen mailbox stays worth stealing. Move it.
Workable
The code is worth stealing for 1 hour at most, and it dies the moment somebody uses it.
The email has to arrive, and the link has to land somewhere
Two problems are specific to mobile and neither shows up until the first tester complains. The first is delivery. Email from a brand new sending domain goes to spam often enough that you should assume it will, which is why people pay for a sending service, set up SPF, DKIM and DMARC records on the domain, and watch bounces for the first month. A reset flow that silently fails to deliver looks identical to a broken account.
The second is where the link opens, and this is where a reset password flow in a mobile app gets harder than the same flow on the web. Tapped inside a mail app, a URL opens a browser, not your app. You either finish the job on a hosted web page and hand the app a session afterwards, or you set up universal links on iOS and app links on Android so the same URL opens the installed app. The second is the better experience and costs a day of work on an association file that has to be served over HTTPS from the same domain as the link.
There is a way around both problems. Send a short numeric code instead of a link and have the user type it into the app. No deep link configuration, no browser detour, and the code never leaves the screen it belongs to. NIST asks for at least six decimal digits from an approved random generator for an issued recovery code, so six digits is the floor rather than the target. Pair it with hard throttling, because a six digit space is small enough to guess at speed.
What to accept as the new password, and what to do next
The reset screen is where plenty of apps quietly make things worse. NIST is explicit that composition rules shall not be imposed, meaning no forced mixture of capitals, digits and symbols, and that users shall not be made to change passwords on a schedule. What it asks for instead is length, a minimum of 15 characters where the password is the only factor, and a check against a blocklist of common, expected or compromised values. The 15 character floor is written for federal systems and most consumer apps will not survive it. The blocklist check is the part worth copying either way, because it is what stops the reset handing the account to the next credential stuffing run.
Two things have to happen once the password changes. Send an email to the address on file saying the password was changed, and never put the password in it. Then end the other sessions, or at least offer to. If the reset happened because somebody else got in, leaving that session alive undoes the whole exercise. OWASP also advises against signing the user straight in from the reset link, because it welds two separate pieces of authentication code together and that is where the bugs live. Send them to the normal login screen instead.
Past that point you are not building a reset flow any more. You are building the account: how long a session lasts, what happens on a new device, and what the person is allowed to do once they are back inside. That is the account behind the password, and it is a separate job with its own decisions.
Ways to let somebody back into their account
| Method | Needs your own server | Needs a sender | Safe if the inbox is taken | What it costs you |
|---|---|---|---|---|
| Emailed reset link | Yes | No | deep link setup | |
| Emailed six digit code | Yes | No | one extra screen | |
| Texted six digit code | Yes | SMS | not against SIM swap | a fee per message |
| Security questions | Yes | No | Yes | answers people can look up |
| Hosted auth provider | theirs | theirs | No | a fee per user |
Building the two screens without building the plumbing
The two screens are a morning. The token store, the expiry, the hashing, the throttling and the email sending are the rest of the week, and none of them live in the app. That split is the honest answer to how long this takes, and it is why so many teams reach for a hosted auth provider and spend their week on the thing the app is actually for.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and ships it to TestFlight and to Google Play internal testing. It is $25 a month and there is no free plan. It does not ship a backend or an email service, so a reset flow still means a provider or a server of your own. The code comes out through two way GitHub sync, as a ZIP, or through the CLI, so wiring that backend in later is not a trap.
Whichever way you go, write the flow down before you build it. Six steps, one expiry, one use, one notification email, other sessions ended. A reset that skips any of those is not finished, it is just quiet about it.
Questions people ask about password reset
Six steps. Take an email address, answer the same way whether or not the account exists, generate a random token and store only its hash with an expiry, email a link or code containing it, verify it and let the user set a new password, then delete the token, send a notification email and end the other sessions. The app supplies two screens. The rest sits on a server.
Describe the app, including the way people get back in
Write down the two screens, the expiry you want and what happens to the other sessions, and build the account flow around that instead of bolting it on later.
Start building