Add Password Reset & Email Verification to Any Web App With Supabase

Confirm Email Sign-In Works

Verification and password recovery are added to the email sign-in your app already has.

People can already sign up and sign in to my app with an email and password through Supabase Auth

Add User Authentication to Any Website with Supabase

No email sign-in yet? Set it up first, then come back.

/video/add-user-authentication-supabase

Inspect Your Auth Setup

Nothing changes in this step. The AI maps what your sign-in already does and what is missing.

Check the Auth Setup

Let AI map your sign-up, sign-in, auth routes and redirect settings, then list exactly which verification and recovery pieces are missing.

I want to add email verification and password recovery to this app's existing Supabase email and password sign-in, and make its auth emails production-ready. Inspect the project first. Do not change any files in this task. Find and report: - The framework and build system, and whether pages render in the browser, on the server or both - How the Supabase client is set up, and which Supabase packages and versions the app uses — for example supabase-js alone, or a server-side helper package too - The current sign-up flow: what happens right after sign-up, and whether the app treats the user as signed in - The current sign-in and sign-out flows - Protected routes, and how they check for a session - Any auth callback or confirmation route, and how it handles a link from an email - Any existing forgot-password or new-password pages, and what they do - All existing auth pages and routes - Where the code sets redirect addresses for auth emails, such as emailRedirectTo and redirectTo values - The production domain the app expects, if the project shows it - The environment variables used for Supabase and the site address — names only, never values - Any existing resend-verification behaviour - Other sign-in methods, such as Google Login, that must keep working - Any Supabase secret or service-role key in frontend code — names and files only Some settings live only in the Supabase Dashboard. List the ones you need me to check and report back — for example whether Confirm email is on, the current Site URL and Redirect URLs, the password requirements, and whether custom SMTP is set up. Then give me: 1. What already works 2. What is missing — email verification, resend, forgot password, the new-password page, invalid-link handling, redirect settings, auth emails 3. What can be reused 4. The routes and pages to add or update, with their exact paths — keep existing paths such as /forgot-password or /update-password if the app already has them 5. The exact redirect URLs the finished flow will use in production — plus local development ones only if I test email links locally 6. A short implementation plan, in order Rules for the plan: - If verification or recovery is partly built, complete it — never build a second flow next to it - Use Supabase Auth's own verification and recovery — never a custom token or reset table - Keep the existing sign-up, sign-in, sign-out and other sign-in methods working, and keep the existing design - Make the smallest safe changes Wait for my approval before changing anything.

Check the Dashboard settings the AI asks about, and paste what you find back into the same conversation. Keep this conversation open — every later prompt builds on the plan.

Approve the Plan

The plan lists what already works and what is missing

It reuses my existing sign-in, sign-up and auth pages

It names the exact routes and redirect URLs the finished flow will use

It keeps my other sign-in methods working

Expected result

You know exactly which account-recovery pieces are missing.

Set Your Site URL and Redirect URLs

Supabase only sends users back to addresses you allow here.

Authentication URL Configuration

Set Site URL to your production domain, such as https://yourapp.com Add each exact redirect URL from the plan, such as https://yourapp.com/update-password Add a local development URL only if you test email links on your computer Save

Use exact addresses for your production domain rather than a broad wildcard, so a link can only ever return to your own pages.

Expected result

Your real domain is the Site URL, and every page the emails link to is allowed.

Turn On Email Confirmation

Authentication Sign In / Providers

Open Email Turn on Confirm email if it is off, and save Note the minimum password length and any required characters — the new-password page will follow them

Expected result

New email sign-ups must now confirm their email address before they can sign in.

Update Sign-Up and Verification

A clear "check your email" state, a working verification link and a resend button.

Add Email Verification

Show a "check your email" state after sign-up, handle the verification link for your framework, and add a resend button with a cooldown.

Now add email verification, following the approved plan. Confirm email is turned on in Supabase, and the Site URL and Redirect URLs are set. If the approved plan is not in this conversation, STOP and ask me for it. Use the current Supabase Auth API for this app's framework, following Supabase's current documentation — check it rather than relying on memory. Sign-up: - Pass the confirmation route from the plan as the email redirect, so the link returns to this app's real domain — never a hard-coded localhost address in production - When sign-up returns no session, treat it as success: show a clear "check your email" state in the existing design, such as: Check your email. We've sent you a verification link. Open it to finish creating your account. - Do not sign the user in, and do not send them to protected pages, before they verify - Do not reveal whether an email address already has an account. Show the same "check your email" state either way. Confirmation: - Handle the verification link the way this architecture needs — the current client-side flow for a browser-only app, or a server route that exchanges the token for a session in a server-rendered app - If this architecture needs the Confirm sign up email template to link to a confirmation route, give me the exact link to paste, keeping Supabase's template variables exactly as they are - After verification succeeds, recognise the new session and send the user to a sensible page, such as the dashboard - Avoid loops: an already verified or signed-in user who opens the link again lands somewhere sensible, not on an error - A failed or expired link shows a friendly message with a way to get a new one — never the raw Supabase error Resend: - Add a Resend verification email action to the "check your email" state, and wherever a user is told their email is not confirmed yet - Use Supabase's resend method for sign-up confirmations, with the same email redirect - Show a loading state, a clear success message, and a short cooldown — for example 60 seconds — during which the button is disabled - Show the same message whether or not the address has an account Keep the existing sign-in, sign-out and other sign-in methods working. Reuse the existing auth handlers — do not add a second one. Give me: 1. What you changed, and where 2. Any template link I need to paste, and which template it goes in 3. How to test it Run the project's build afterwards.

If the AI gave you a link for the Confirm sign up template, paste it into that template now. If Supabase does not let you edit templates yet, set up custom SMTP first — Step 5 — then come back.

Authentication Emails Templates

Expected result

The app now shows a "check your email" state after sign-up, with a working resend button.

Verify a Test Account

Until custom SMTP is set up in Step 5, Supabase only emails addresses on your own Supabase team — so test with your own email.

Sign up with an email address you own that has no account yet Check that the app asks you to check your email and does not open protected pages Open the verification email and follow the link

Expected result

A new account must verify its email before entering the protected app, and the link returns to your correct domain.

Add the Forgot Password Page

One message for every email address, so the form never reveals who has an account.

Add Forgot Password

Add a Forgot password? link and a request page that sends Supabase’s recovery email — with the same message for every address.

Now add the forgot-password request, following the approved plan. If the approved plan is not in this conversation, STOP and ask me for it. - Add a Forgot password? link to the existing sign-in page - Use the forgot-password page from the plan — complete it if it already exists — in the existing design - The user enters their email address. Check its format before sending. - Call Supabase's current password-reset method with the new-password route from the plan as the redirect. It must match an allowed Redirect URL exactly. - Show a loading state, then ALWAYS the same message, whether or not the address has an account: If an account exists for this email, we've sent password reset instructions. - Never show a different message, delay or error for addresses that have no account. Rate-limit and network problems get one safe, general message. - Add a link back to sign in - No security questions, and no custom reset tokens — Supabase Auth's recovery email is the only mechanism Give me: 1. What you changed, and where 2. How to test it Run the project's build afterwards.

Expected result

The sign-in page has a Forgot password? link, and the request page is ready.

Send a Test Reset Request

Sign out and select Forgot password? on the sign-in page Submit your own email, then an address with no account Check that both show exactly the same message Open the reset email and check its link points to your app’s new-password page — you build that page next

Expected result

Submitting the form sends the Supabase recovery email, and its link points to your app’s reset-password route.

Build the New Password Page

The form works only inside a real recovery session — a direct visit shows a way to request a new link.

Build the New Password Page

Build the page reached from the reset email: a real recovery session only, your project’s password rules, and friendly invalid-link and success states.

Now build the new-password page that users reach from the reset email, following the approved plan. If the approved plan is not in this conversation, STOP and ask me for it. Use the current Supabase recovery flow for this app's framework, following Supabase's current documentation: - In a browser-only app, the link brings a recovery session, and Supabase signals a password recovery event - In a server-rendered app, a server route exchanges the token from the link for a session before the form is shown - If this architecture needs the Reset password email template to link to a confirmation route, give me the exact link to paste, keeping Supabase's template variables exactly as they are The page: - Show the form only when a real recovery session exists. Opening the page directly, with a used link, or with no session shows: This reset link is invalid or has expired — with a button, Request a new password reset link, that goes to the forgot-password page. - Fields: new password and confirm new password - Use the password rules this Supabase project actually enforces — the minimum length and any required characters I report from the Dashboard — and show them before the user submits. Do not invent stricter rules. - Check that both passwords match before submitting - Update the password with Supabase's current method for the recovery session - Show a loading state, then a clear success message - After success, end the recovery state cleanly: either keep the user signed in and send them into the app, or sign them out and send them to sign in. Choose what fits this app, and tell me which. - Turn Supabase errors into friendly messages — for example a password that is too weak, or the same as the old one. Never show the raw error. Keep any existing change-password screen for signed-in users exactly as it is. This task is only about recovering a forgotten password. Give me: 1. What you changed, and where 2. Any template link I need to paste, and which template it goes in 3. How to test it, including an invalid link Run the project's build afterwards.

If the AI gave you a link for the Reset password template, paste it into that template now:

Authentication Emails Templates

Expected result

The new-password page is ready, and a direct visit asks the user to request a new link.

Reset Your Test Password

Request a password reset for your test account Open the newest reset email and follow the link Choose a new password and submit it Sign in with the new password

Expected result

You requested recovery, opened the email link, chose a new password, and signed in with it.

Set Up Custom SMTP

Supabase’s built-in email only reaches your own team’s addresses, two emails an hour — fine for testing, not for real users. If custom SMTP is already on, check the sender and the rate limit.

1. Choose an email provider

Use a provider you already have, or one Supabase lists, such as Resend, Postmark, Amazon SES or Brevo.

2. Verify your domain

Add your domain in the provider, create the DNS records it shows — SPF, DKIM and usually DMARC — at your DNS host, and wait until the provider marks the domain verified.

3. Connect it to Supabase

Create SMTP credentials in the provider. Then turn on Enable Custom SMTP and enter the sender email — such as no-reply@yourdomain.com — your app’s name as the sender name, and the host, port, username and password. Save.

Authentication Emails SMTP Settings

4. Check the email rate limit

Custom SMTP starts at 30 emails an hour. Raise it if your app expects more sign-ups and resets than that.

Authentication Rate Limits

Keep SMTP credentials in Supabase

Your SMTP password lets anyone send email as your domain. Enter it only in Supabase’s SMTP settings — never in frontend code, an environment file, the repository or the AI conversation.

Expected result

Supabase sends auth emails through your provider, from your own domain.

Brand the Auth Emails

Simple emails that clearly come from your app, with Supabase’s links left intact.

Write the Auth Emails

Write simple Confirm sign up and Reset password emails in your app’s identity, built only from Supabase’s own link variables.

Now write my two Supabase Auth email templates — Confirm sign up and Reset password — so they clearly come from this app. If the approved plan is not in this conversation, STOP and ask me for it. For each template, give me: - A subject line - A short, simple HTML body: the app's name, one sentence saying what the email is for, one clear button, and a line saying what to do if they did not ask for this email - The link, built only from Supabase's own template variables. Use the link Supabase's default template uses for this email — or, if you gave me a confirmation-route link earlier for this architecture, that exact link. Never hard-code an address with a token in it, and never invent a variable. Keep it plain: no tracking pixels, no external images that could break, and no personal details beyond what Supabase already puts in the email. Tell me which template variables you used and why, so I can check them before I paste.

Authentication Emails Templates

Open Confirm sign up, paste the subject and body, and save Open Reset password, paste the subject and body, and save Under security notifications, turn on Password changed so users hear about a password change they did not make

Leave the link variables intact

If a template’s link variable is changed or removed, every verification or reset email stops working. Check the link before you save.

Expected result

Verification and reset emails arrive reliably from your app’s sender and send users back to your production domain.

Test Everything End to End

Real emails and real sign-in state, with a fresh test account on the live site.

Test Account Recovery

Test verification, resend, forgot password, new password, broken links and production settings with real emails on the live site.

Help me test the complete account flow with real emails and real sign-in state. Checking the screens alone is not enough. If the approved plan is not in this conversation, STOP and ask me for it. Test on the live site after the latest changes are deployed, with a fresh email address that has never had an account. Walk me through each test, and tell me what to check: Email verification 1. Create a new account 2. Sign-up does not open protected pages before verification 3. The verification email arrives from my app's sender 4. Open the verification link 5. It returns to my app's real domain 6. The account can now use the signed-in part of the app 7. Resend verification works for a new, unverified account 8. Clicking resend repeatedly is held back by the cooldown and causes no confusing behaviour Password reset 1. Sign out 2. Open Forgot password? 3. Submit the test account's email 4. Submit an address with no account, and check the message is exactly the same 5. Open the real reset email 6. The link opens the new-password page on my real domain 7. Enter a new password 8. The update succeeds 9. Sign in with the new password 10. The old password no longer works Failure states - A reset link that was already used - An expired or broken reset link - A badly formatted email address - Opening the new-password page directly, without a link, does not allow a password change - No wrong or leftover redirect URL is still in use Production settings - The Site URL is the real production domain - Every redirect URL the app uses is allow-listed, with exact URLs in production - No localhost or test address controls the emails production users receive - Custom SMTP is sending the emails - No SMTP password or Supabase secret key appears in frontend code or the repository - Both email templates open the right pages - Other sign-in methods, such as Google Login, still work if the app has them If a link says it has expired the moment it is opened, tell me whether an email security scanner may be opening links first, and the simplest fix for this app. Report expected versus actual for every test, then finish with exactly one verdict: ACCOUNT RECOVERY READY or NEEDS ATTENTION If NEEDS ATTENTION, list only what is still failing. When everything passes, remove any temporary test-only code and run the build.

Continue when the AI reports ACCOUNT RECOVERY READY. If it reports NEEDS ATTENTION, fix the listed issues and run the test again.

Confirm Your Production Settings

The Site URL is my real production domain

Only my app’s exact pages are allowed as production redirect URLs

Auth emails arrive through custom SMTP from my app’s sender

Both email templates open my app’s own pages

Your Supabase authentication now supports verified accounts and secure password recovery, with production-ready email delivery and redirect handling.