Password reset should not act as OTP

[dmudro]

for email based accounts there is a '3 step instustry standard' password reset flow:

1. user has the option to submit a "forgot password" form where they detail their email address. easy in Supabase by calling supabase.auth.resetPasswordForEmail
2. the user receives the password reset email
3. upon clicking on the {{ .ConfirmationURL }}(containing reset token) in the email, the user is presented custom form to change their password.

this is all standard stuff and pretty much same with any identity provider using email / password based sessions.

in Supabase, however, step 3 acts as OTP and redirecting the user with confirmationURL signs them in automatically and before they've changed their password. the same is true when validting the token via SDK manually on the client. hence this password reset flow effectively works as OTP which is not necessarily always desired. in my instance I do want the user to manually sign in after they've successfully changed their password.

a possible solution to implement a custom reset flow:

1. custom reset URL defined in Supa email template as: {{ .SiteURL }}/new-password?email={{ .Email }}&amp&token={{ .TokenHash }}
2. once landed on new-password?email=<value>&token=<value>, a password change form is presented; at this point the user does not have a session
3. user submits the form with new password calling my own serverside API route
4. that endpoint does a couple of things on the server:
   a) validates the token with spbs.auth.verifyOtp({ type: 'recovery', token: '<value>', email: '<value>'})
   b) when successful, update user's password with supabase.auth.admin.updateUserById
5. password is succesffully updated but the user stays signed out - this is what I am after

are there any flaws n my logic?

would it be worth providing a out of the box experience with SDK, e. g. by implementing something like a separate spbs.auth.verifyToken method as opposed to spbs.auth.verifyOtp as the latter signs in and creates the session automatically.

thanks for considering!

[dmudro]

my previous suggestion for custom backend token validation would not work:
{{ .SiteURL }}/new-password?email={{ .Email }}&amp&token={{ .TokenHash }}

...as tokenHash is not good for the verifyOtp method. just learned what tokenHash is for in this PR.

it would work by passing a plain {{ .token }} which I don't think looks secure.

I could probably write my own validate function to read user.recovery_token in the auth scheme on the backend and subsequently set new password with the admin api as suggested above. but then what's the point using Supabase BaaS.