Today, commerce is everywhere — shoppers are not only buying products on traditional eCommerce websites, but they’re also making purchases on mobile phones, social channels, smart devices, and even IoT devices. With the new Shopper Login and API Access Service (SLAS), Commerce Cloud is helping developers level up security and trust in all kinds of headless commerce builds.

What is the Shopper Login API?

This API and service is a high scale authentication and authorization solution that provides secure access to the Commerce platform’s Shopper APIs. It enables merchants to develop functionality that lets shoppers log in via federation to an Identity Provider (IDP) of their choice. Critical to SLAS is the introduction of OAuth 2.0-based login APIs, which use the refresh-token pattern to allow a shopper to log in once and retain the login for up to 90 days.

Benefits for developers

• Implement secure API access that prevents security vulnerabilities, such as cross tenant data access, or prevents the exposure of semi-private information, such as product availability during hype sales.
• Adopt Commerce APIs with a phased approach by seamlessly switching between the new Salesforce Commerce API (SCAPIs) and existing Open Commerce API (OCAPIs) using the same SLAS access token for a given headless application.
• Implement secure login for API access for all kinds of headless applications (full stack web apps, web apps with server side BFF (private clients), single page apps, and mobile/native apps (public clients).
• Implement industry-specific authentication needs (finance, telco, insurance).

Benefits for shoppers

• Log in using a third-party identity provider (e.g., Google, Facebook, Auth0, Ping).
• Use single sign-on for sites built with Commerce Cloud, Experience Cloud, and other Salesforce products.
• Get a more personalized shopping experience. SLAS API responses include unique identifiers for guest and registered users that can be used with Commerce Einstein’s activity-tracking APIs.
• Stay logged in for longer and retain access to the shopping cart.
• Access services powered by Commerce Cloud’s Shopper APIs (with support for both Commerce API and OCAPI).

How does the Shopper Login API work?

SLAS provides high-scale login and API access for a wide variety of headless applications. This is typically a three-step process:

1) The shopper logs in with an external (Google, Auth0, etc.) or internal (B2C Commerce system) identity provider.
2) The app gets an access token with all the Shopper API scopes.
3) The app uses the access token as a key to access all B2C Commerce Shopper APIs.

SLAS uses standard OAuth 2.0-based login flows for different kinds of headless applications. For web apps with server-side back-end for front-end (BFF), where you can store a client secret securely on a front-end, you’ll need to implement client_credentials grant for guest users, an authorization code flow for registered users federating login to an external IDP, and authorization_code_pkce for logging shoppers into the B2C Commerce system.

For single page apps (SPAs) or mobile/native apps, you’ll need to implement variations of authorization_code_pkce flows for anonymous and known users. These flows are detailed in the developer guide.

With the SLAS GA release in April 2021, we’ve enabled developers to level-up their customer implementations to support two different categories of headless applications:

1. Web applications with a server side backend or BFF using private clients
2. Mobile/native applications or single page applications using a public client. All customers that will use our PWA Kit will use this second pattern.

These two patterns, generally available today, both involve user interaction when logging in. In addition, we’ve received requests to enable a third pattern, which is trusted system login on behalf of a shopper. This pattern doesn’t involve a shopper logging into the B2C commerce system directly. Instead, a trusted app requests or updates a shopper’s information on behalf of the shopper (who is already authenticated). Using this pattern, the trusted app can request or update a shopper’s profile details, baskets, orders, etc. This pattern is typically used by developers who authenticate shoppers using a third-party/home-grown IDP themselves and would like authenticate with the B2C Commerce system as a trusted app on behalf of the shopper.

The trusted application could be internal or external. Examples of internal trusted system applications are Experience Cloud or Salesforce Order Management. External trusted applications could be any external application that needs to interact with the Commerce Cloud platform at scale on behalf of shoppers. Examples of an external trusted application include the Avalara tax app that adjusts taxes in a shopping cart, or social selling aggregator apps like GoDataFeed and ChannelAdvisor that insert orders back into the system. The trusted system pattern is available now.

Get started

SLAS is a very powerful mechanism to drive a secure login experience for your headless commerce applications. We’re working on providing you practical examples in the next couple of months, so that you can dig deeper on how to implement them in your applications.

If you’re an existing Commerce Cloud customer, you can set up SLAS for your B2C Commerce system today. And we encourage everyone to check out our API specification, to learn more about the different endpoints that SLAS provides.

About the Author

Bhagath Ganga is a Director of Product Management at Salesforce.