Passwordless Login

Learn about passwordless login and how to use the Shopper Login and API Access Service (SLAS) to offer it to your shoppers.

Passwordless login is a way to verify a user’s identity without using a password. It offers protection against the most prevalent cyberattacks, such as phishing and brute-force password cracking. Passwordless login systems use authentication methods that are more secure than regular passwords, including magic links, one-time codes, registered devices or tokens, and biometrics.

Using SLAS to offer passwordless logins can benefit both shoppers and merchants.

Simpler and Safer

Password management is a hassle. To save time, users often create short passwords that are easy to remember or use the same password over and over. But these timesavers increase the risk of cyberattacks. Passwordless login saves users even more time than these risky password management shortcuts because there’s no password to manage: they can authenticate using their email or phone.

Cost Effective

Password-related costs can really add up. Merchants need to implement systems for storing user credentials securely and in compliance with local privacy laws. Support teams spend time dealing with accounts that have been hacked or have been locked to prevent hacking. By reducing password usage, merchants can save on all password-related costs.

To understand how passwordless login works with SLAS, let’s look at an overview of the process flow:

1. The shopper opens the shopping app (your online storefront) and initiates passwordless login (usually via the login page).
2. The app uses SLAS to initiate a passwordless login and generate a passwordless token.
3. SLAS looks up the user’s credentials and makes a request to a callback URI that has been previously registered as part of the SLAS API client configuration. The callback is used to provide the app with the passwordless token and the user’s contact information.
4. The app handles the callback and sends a message (either via email or SMS) to the shopper. The message contains a login link with a passwordless token.
5. The shopper opens the message (before the token expires) and clicks the passwordless login link.
6. The app exchanges the passwordless token for an access token and validates the user’s credentials.
7. The shopper is logged in and the application can make authorized requests to the Shopper APIs using the access token.

Now that you understand how passwordless login systems work in general and how a passwordless login flow works with SLAS, you’re ready to start your own implementation. To configure and implement a passwordless login system using SLAS, follow the step-by-step instructions in the remaining sections of this guide.

Before you can configure SLAS for passwordless login, you must prepare a callback URI (or multiple URIs) for handling the POST request from SLAS that contains the user’s credentials and passwordless token. The URI must be publicly accessible, so you need to use a tool like ngrok to expose a localhost endpoint externally.

In the sample code provided in this guide, we’re using https://webhook.site/47d361be-567d-4421-a5a3-6697d844d236 as a placeholder value for the callback URI. Don’t forget to replace this placeholder with your actual callback URI!

If you need to change the URI, you can update your SLAS configuration at any time.

If you haven’t already created a private client using the SLAS Admin UI, follow the instructions in Authorization for Shopper APIs to create one and come back to this guide. Only private clients can be used for passwordless login.

To configure a private client for passwordless login, follow these steps in the SLAS Admin UI:

1. From the top navigation, click Clients.
2. Click the Edit link next to the client ID that you created earlier.
3. In the Scopes field, add sfcc.pwdless_login.
4. In the Callback URL field, enter the callback URI that you prepared earlier.

Imagine you’re building passwordless login flow for a storefront hosted on example.com. The customer starts the flow from a page at example.com/login. They enter their username and click a button to request a passwordless login link via email or SMS. To authorize the customer, make a request to the Authorize passwordless customer endpoint. The endpoint validates the credentials and makes a POST request to the callback specified in the callback_uri parameter. The callback must be added to the API client’s configuration.

Sample Code

The following shell script demonstrates how to authorize the customer in a passwordless flow.

The user_id parameter must be the shopper’s actual login credential (profile.credentials.login). Although the login credential can be an email address (as in our sample), it’s not guaranteed to be the same as profile.email.

Callback Example

Here’s an example request that demonstrates what headers and parameters are provided when SLAS makes a callback request:

Let’s take a closer look at the JSON in the request body from the callback example:

The JSON contains both an email address and a phone number that belongs to the customer so that you can send them either an email or an SMS. The value of phone is set to the value of phoneMobile in the B2C Commerce system. If phoneMobile is not available, SLAS uses the value of phoneHome or phoneBusiness instead.

Use the value of token to create the passwordless login link that you provide for the shopper in the body of the email or SMS. For example, example.com/login/DSRWHAVBRSB4G5HVFP3G5R64Z55NDKAA.

Important: A passwordless token is valid for only 10 minutes and can only be used one time. Given that these messages are time sensitive, consider using a transactional email or SMS service.

When handling passwordless login links, you can make a request to the Get passwordless access token endpoint to exchange the passwordless token for an access token (Shopper JWT).

Sample Code

The following shell script demonstrates how to get an access token:

The access token (Shopper JWT) returned by SLAS can now be used to make calls to the Shopper APIs.

Important: These instructions apply only if your storefront is built using the Storefront Reference Architecture (SFRA) or SiteGenesis.

To use the passwordless login features provided by SLAS with SFRA or SiteGenesis requires a technique called session bridging. Session bridging uses cookies to share session tokens across different systems.

The access token (Shopper JWT) obtained from SLAS can be used to make a request to OCAPI’s /sessions endpoint.

All Set-Cookie headers for handling the session are applied on the response and can be applied directly to the storefront architecture. Examples of this approach are available in the plugin_slas cartridge.

Sample Code

The following shell script demonstrates how to use OCAPI with a SLAS access token (Shopper JWT):

For more information on session bridging, see OCAPI session bridge 22.6 in the Infocenter and Phased Headless Rollouts in the PWA Kit documentation.

For more technical details on the capabilities of the SLAS APIs, explore the API specifications in the Reference section:

• SLAS API
• SLAS Admin API