Shopper Login (SLAS) Overview

The Shopper Login and API Access Service (SLAS) enables secure access to the Shopper APIs of the B2C Commerce API and the Open Commerce API (OCAPI).

We offer two admin tools for setting up SLAS: the SLAS Admin API and the SLAS Admin UI. Both admin tools use Account Manager for access control, and they both require that you have the SLAS Organization Administrator role and the correct filters applied for your B2C Commerce instances.

To access the SLAS Admin UI, replace {{short-code}} in the following URL with the short code used by your B2C Commerce instances:

To learn more about Commerce Cloud short codes, see the Configuration Values guide.

For advice on how to use SLAS under high-volume situations, see this article on the Salesforce Developers blog: Shopper Login API: Techniques and Tricks to Get the Most Out of High-Volume Holidays.

To make authorized requests to SLAS, each application must be associated with one or more SLAS clients. Each SLAS client is registered to a single SLAS tenant and each SLAS tenant is associated with a single B2C Commerce instance.

A SLAS client can be created as one of two types: public or private. To choose the right client type for your application, the most important thing to ask is whether the client can be trusted to securely store a client secret or not. Use a private client when you can trust the client and use a public client when you cannot.

For example, a mobile app that communicates directly with SLAS must store the client secret on the shopper’s device, which is not secure. Therefore, most mobile apps use a public client. On the other hand, a mobile app with a backend for frontend (BFF) system can store a client secret in a secure location where the shopper’s device cannot access it. Any app with a BFF system can use a private client.

The following table summarizes which client types are used by the most common types of applications:

The SLAS API is based on grant types defined by the OAuth 2 standard.

The grant type used for an access token request depends on the type of SLAS client (public or private) and the shopper’s authentication method.

Most SLAS clients request access tokens with the getAccessToken endpoint and receive a ShopperToken.

Trusted systems use the getTrustedSystemAccessToken endpoint and receive a ShopperTsob token. This token has additional capabilities so that trusted systems can make requests on behalf of users.

The following table summarizes the different grant types and token types used by each type of SLAS client and user authentication method.

To request a ShopperToken, use the getAccessToken endpoint. To request a ShopperTokenTsob, use the getTrustedSystemAccessToken endpoint.

Both endpoints return the following upon successful authorization:

• An access token in JSON Web Token (JWT) format
• A customer_id string
• A unique shopper identifier (USID)
• A refresh token

Access tokens are valid for 30 minutes. They can be used to make requests to any B2C Commerce API endpoints covered by the scopes of the issuing SLAS API client. They can request Open Commerce API endpoints for which the SLAS API client ID has been allowed. They may only be used to request APIs from the instance and site they were issued.

The refresh token can be used to request a new access token. For production tenants, refresh tokens are valid for 90 days for registered shoppers and 30 days for guests. On non-production tenants, refresh tokens are valid for 9 days. Using the refresh tokens extends the lifetime of the subsequently issued token by its lifetime duration.

Refresh tokens issued to using public clients are single use. When the refresh token is used, a new one is returned in the response. Refresh tokens issued using private clients may be used multiple times. The same refresh token is returned in the response.

• When a shopper changes their password, any access tokens that were granted before the password change are rejected by both the B2C Commerce API and OCAPI. After a password change, use a refresh token to get a new access token or prompt the shopper to authenticate again.
• The JWT returned by SLAS includes a number of claims. When writing code to inspect claims, be sure not to rely on ordering, as additional claims may be added.
• Access tokens allow you to act on behalf of the shopper. The actions taken can be sensitive, such as updating an account's email. Always take the necessary precautions to protect the shopper.

SLAS supports the following rate limits:

• 24,000 requests per minute (RPM) per tenant for production instances.
• 500 RPM per tenant for non-production instances.
• 25 RPM for the following endpoints: getJwksUri and getWellknownOpenidConfiguration

When a rate limit is reached, SLAS responds with an HTTP 429 Too Many Requests with an HTTP response header Retry-After. The value in the Retry-After header is set to the time in seconds to wait before retrying the request:

Your client code must be able to handle this response. To ensure that the next request is successful, always wait for the specified time before retrying.

Some SLAS including authenticateCustomer communicate with the associated B2C Commerce instance. If the instance is unavailable, calls to these endpoints will fail.

SCAPI hooks including hooks on dw.ocapi.shop.customer.auth.* can conflict with SLAS calls. If SLAS calls are unexpectedly failing, check your B2C Commerce logs for hook invocation errors.

If you haven’t already, set up your public SLAS clients or private SLAS clients by following the instructions in Authorization for Shopper APIs in the Get Started guides.

After setting up your SLAS clients, see the SLAS guides that cover how to use both the main SLAS API and the SLAS Admin API:

• Public SLAS Client Use Cases (main SLAS API)
• Private SLAS Client Use Cases (main SLAS API)
• SLAS Identity Providers (SLAS Admin API)

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

• SLAS API
• SLAS Admin API