Customer Accounts

Registering a customer account

The registerCustomerAccount mutation is used to register a new customer account.

There are four possible registration flows. If authOptions.requireVerification is set to true (the default):

1. The Customer is registered with a password. A verificationToken will be created (and typically emailed to the Customer). That verificationToken would then be passed to the verifyCustomerAccount mutation without a password. The Customer is then verified and authenticated in one step.
2. The Customer is registered without a password. A verificationToken will be created (and typically emailed to the Customer). That verificationToken would then be passed to the verifyCustomerAccount mutation with the chosen password of the Customer. The Customer is then verified and authenticated in one step.

If authOptions.requireVerification is set to false:

3. The Customer must be registered with a password. No further action is needed - the Customer is able to authenticate immediately.

Whatever the setting, if an account already exists for that email address through another authentication strategy (for example an SSO provider) and has no password yet:

4. The supplied password is never stored. A verificationToken is created and emailed to the address, and the mutation answers { success: true } exactly as it does for a new account, so it does not reveal that the account exists. The password is set only when that token is passed to the verifyCustomerAccount mutation with the chosen password, which proves the caller controls the mailbox. This holds even when requireVerification is false, so a storefront must not assume it can log the customer in straight after registering. Registering again sends the verification email with a fresh token, for as long as the credential still holds no password. Once it holds one, registering against the address does nothing, the same as for any fully registered account.

The caller-supplied firstName, lastName, phoneNumber and custom fields are ignored whenever an account already exists for the address, since the caller has not proven they own it. That includes an account an administrator created earlier: such a customer registering for themselves keeps the details the administrator entered. A Customer left by a guest checkout has no account attached, so its details are still filled in.

Here's a diagram of the second scenario, where the password is supplied during the verification step.

Here's how the mutations would look for the above flow:

Note that in the variables above, we did not specify a password, as this will be done at the verification step. If a password does get passed at this step, then it won't be needed at the verification step. This is a decision you can make based on the desired user experience of your storefront.

Upon registration, the EmailPlugin will generate an email to the customer containing a link to the verification page. In a default Vendure installation this is set in the vendure config file:

The verification page needs to get the token from the query string, and pass it to the verifyCustomerAccount mutation:

Password reset

Here's how to implement a password reset flow. It is conceptually very similar to the verification flow described above.

A password reset is triggered by the requestPasswordReset mutation:

Again, this mutation will trigger an event which the EmailPlugin's default email handlers will pick up and send an email to the customer. The password reset page then needs to get the token from the url and pass it to the resetPassword mutation: