important

This is a contributors guide and NOT a user guide. Please visit these docs if you are using or evaluating SuperTokens.

Reset Password token generation should take userId or not

Status:: accepted
Deciders:: rishabhpoddar, bhumilsarvaiya
Proposed by:: bhumilsarvaiya
Created:: 2022-11-24

Context and Problem Statement#

Currently the create password reset token API takes userId as input. The token created for password reset purpose is stored in a table along with userId. After the account linking changes, the userId passed can be either recipeUserId or primaryUserId. If the passed userId is primaryUserId and different emails are associated with it, during the token consumption API, it won't be possible to know for which email, the email password recipe user needs to be created for.

Considered Options#

Update the core API for password reset token generation to take userId as well as email as input.
Just have email as input for password reset token generation API and remove userId dependency.

Decision Outcome#

We have chosen to go with the first option. The reasons are:

it solves the issue where if the passed userId is primaryUserId and different emails are associated with it.
removing a user will no require any additional changes. If we only take email as input and no longer take userId, while deleting the user, the core would have to perform an additional step of getting email for user and removing it. Also, it would only make sense to perform this step while removing an emailpassword user. For example if there exists two user with same email, one with TP and one with EP. If we want to remove TP user, the password reset token generation row for this user should not be removed. To avoid such overheads we just go with the first option and store both email and userId in password reset token generation table. UserId can be either a recipeUserId or primaryUserId.