Other Customer Operations

Login with a JWT

An alternative to the login mutation for authenticating customers is to use the loginWithCustomerLoginJwt mutation. You will need to have a JWT that contains key information in the payload for the login to be successful. See the Customer Login API article for instructions on how to create a JWT. This workflow supports single sign-on scenarios where a trusted application authenticates a customer without requiring their BigCommerce credentials.

Example of a Login mutation with a JWT

mutation Login($jwt: String!) {
 loginWithCustomerLoginJwt(jwt: $jwt) {
   customer {
     entityId
     email
   }
   customerAccessToken {
     value
     expiresAt
   }
 }
}

The customer access token will be returned along with the customer’s entityId and email.

Expanded Customer Information

Once a customer has been authenticated, in addition to simply providing context for general queries, it becomes possible to query detailed information like order history, as well as modify data on the customer record itself. Mutations are available to:

• Update the basic customer information
• Add, modify, and delete customer addresses
• Change the customer’s password
• Initiate a password reset

See the API reference for the full details of these operations.

Managing Passwords

Note that there are two distinct GraphQL Storefront API mutations related to updating a customer’s password:

• customer.changePassword directly updates the customer record, requiring both the current and new password as input. Initiating this action from your storefront requires that a customer know their current password and will fail if this cannot be provided.
• customer.requestPasswordReset requires only the customer’s email address and cannot directly update the record. Instead, an email is sent to the customer with a “password” reset link to complete the process, ensuring that only the owner of the email on record can perform this operation. This is appropriate for the typical “Forgot Password” scenario.

Below is a typical example of a reset action on the server-side of your application (initiated by a “Reset Password” button or something similar):

token = // Storefront token
storeHash = // Store hash
channelId = // Headless storefront channel ID
request = // POST request data
const requestResetPasswordMutation = `
mutation requestResetPassword(
    $email: String!
) {
    customer {
        requestPasswordReset(
            input: {
                email: $email,
                path: "/passwordreset"
            }
        ) {
            errors {
                ... on ValidationError {
                    message
                }
            }
        }
    }
}
`
const customerData = await request.json();
const email = customerData.email;
const resetRequestResult = await fetch(
  `https://store-${storeHash}-${channelId}.mybigcommerce.com/graphql`,
  {
    method: 'POST',
    headers: {
      Accept: 'application/json',
      'Content-Type': 'application/json',
      Authorization: `Bearer ${token}`,
    },
    body: JSON.stringify({
      'query': requestResetPasswordMutation,
      'variables': {
        email,
      }
    }),
  }
).then(res => res.json());

Notice that the optional input parameter path is being sent in the above example. By default, password reset emails sent by BigCommerce will include links to the standard password reset URL path. When you supply the path parameter, these links will be generating using the URL path provided.

The reset link sent to the customer will include both the customer ID and the reset token as querystring parameters:

mystore.com/passwordreset?c={id}&t={reset token}

The associated route in your storefront application should be prepared to use these parameters to complete the operation with the customer.resetPassword mutation.

Resources

• Customer Type
• Customer Mutations