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:
| Application | Client Type |
|---|---|
| Single-page web app (for example, a PWA Kit storefront) | Public client |
| Traditional full stack web app | Private client |
| Mobile app (Android or iOS) | Public client |
| Any kind of app with a backend-for-frontend (BFF) | Private client |
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 Get access token endpoint and receive a ShopperToken.
Trusted systems use the Get trusted system access token endpoint and receive a ShopperTsob token. The ShopperTsob 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.
| SLAS Client | Authentication Method | Grant Type | Token |
|---|---|---|---|
| Public | None (guest user) | authorization_code_pkce | Shopper |
| Public | Registered user (federated login) | authorization_code_pkce | Shopper |
| Public | Registered user (B2C Commerce login) | authorization_code_pkce | Shopper |
| Private | None (guest user) | client_credentials | Shopper |
| Private | Registered user (federated login) | authorization_code | Shopper |
| Private | Registered user (B2C Commerce login) | authorization_code_pkce | Shopper |
| Private | Trusted system on behalf of (TSOB) user | client_credentials | ShopperTsob |
To request a ShopperToken, use the Get access token endpoint. To request a ShopperTokenTsob, use the Get trusted system access token endpoint.
Both endpoints return the following upon successful authorization:
- An access token in JSON Web Token (JWT) format
- A
customer_idstring - A unique shopper identifier (USID)
- A refresh token
Access tokens are only valid for 30 minutes, but the refresh token can be used for up to 90 days on production tenants (9 days on lower level tenants) to request a fresh access token. With a public client, the refresh token can only be used one time, so it’s important to store the new refresh token that is returned when you request an access token. With a private client, you can reuse the same refresh token until it expires or use the new refresh token that is returned.
- 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.
An access token is only valid for a single B2C Commerce instance.
SLAS supports the following rate limits:
- 24,000 requests per minute per tenant for production instances.
- 500 requests per minute per tenant for non-production instances
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: