Private SLAS Client Use Cases

These use cases show how SLAS authorizes access to a Shopper API for private clients under different login scenarios.

Remember that any shopping app that is able to securely store a client secret is a private client. Full stack web apps and all shopping apps with a backend-for-frontend (BFF) must be provisioned as private clients.

Each use case demonstrates a different login scenario: guest user (no login), federated login, and B2C login.

Although all three use cases feature OCAPI’s /baskets endpoint, remember that a SLAS access token can be used with any Shopper API endpoint.

Each step in the authentication flow is numbered and described in detail for all three use cases. The numbered steps are also illustrated with a diagram to help you visualize the process.

See the Shopper Login and API Access Service (SLAS) API reference for full details on how to make your API requests.

Explore these use cases interactively with a Postman collection: Salesforce Commerce B2C SLAS Use Cases.

This use case describes what happens when the shopper adds a product to their basket without logging in first. It follows the client credentials grant flow as defined by the OAuth 2.1 standard.

1. A shopper opens a B2C Commerce shopping app and starts interacting with it.

2. The shopping app requests an access token using the /token endpoint of the SLAS API.

   • The request must include an authorization header that contains a Base64 encoded version of the following string: <clientID>:<clientSecret>. (Don’t forget to replace <clientID> and <clientSecret> with actual values before encoding the string.)
   • Example header value: Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW.
   • The client ID and client secret must be provisioned for the app by a SLAS Organization Administrator. See the SLAS Admin API for more information.
   • Required query parameter: grant_type=client_credentials.
   • Required query parameter: channel_id.
   • Optional query parameter: usid. If you already have a Unique Shopper Identifier (USID) for the guest user, pass it in. Otherwise, SLAS creates a USID for you.
   • Best practice: reuse the USID for a shopper from the previous guest login to tie that user to all the previous login attempts and enable personalization.

3. The endpoint responds with an access token in the form of a JSON Web Token (JWT), a customer_id string, a USID, and a refresh token.

4. The guest shopper adds a product to their basket.

5. The shopping app makes a request to the /baskets endpoint of OCAPI and provides a SLAS access token in the header.

6. The Baskets API saves a shopping basket with a customer_id string that is associated with the guest user.

This use case describes what happens when a shopper logs in using a third-party identity provider before adding a product to their basket. It follows the authorization code grant flow as defined by the OAuth 2.1 standard.

1. A shopper logs in to a B2C Commerce shopping app and chooses a third-party identity provider (IDP) to perform the authentication.

2. The shopping app makes a request to the /authorize endpoint of the SLAS API.

   • Required query parameters: hint, response_type=code, client_id, and redirect_uri.
   • The hint parameter specifies the name of the identity provider.
   • The redirect_uri parameter specifies what app route to redirect to when the login is complete.

3. The SLAS API redirects to the identity provider’s login page.

4. The shopper enters their credentials and consents.

5. If login is successful, the SLAS API responds with an authorization code and redirects to the shopping app.

6. The shopping app requests an access token using the /token endpoint of the SLAS API.

   • The request must include an authorization header that contains a Base64 encoded version of the following string: <clientID>:<clientSecret>. (Don’t forget to replace <clientID> and <clientSecret> with actual values before encoding the string.)
   • Example header value: Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW.
   • The client ID and client secret must be provisioned for the app by a SLAS Organization Administrator. See the SLAS Admin API for more information.
   • Required query parameter: grant_type=authorization_code.

7. The endpoint responds with an access token in the form of a JSON Web Token (JWT), a customer_id string, a USID, and a refresh token.

8. The shopper adds a product to their basket.

9. The shopping app makes a request to the /baskets endpoint of OCAPI and provides a SLAS access token in the header.

10. The Baskets API saves a shopping basket with a customer_id string that is associated with the registered user.

This use case describes what happens when a shopper logs in with credentials that are managed by a B2C Commerce instance before adding a product to their basket. It follows the authorization code grant flow as defined by the OAuth 2.1 standard. It also uses a proof key for code exchange (PKCE), as defined by RFC 7636.

1. A shopper logs in to a B2C Commerce shopping app and chooses to authenticate directly through the shopping app.

2. The shopping app generates two strings: code_verifier and code_challenge.

   • The code_verifier string is a random string.
   • The code_challenge is an encoded version of the code_verifier string using an SHA-256 hash.

3. The shopping app makes a request to the /login endpoint of the SLAS API.

   • The request must include an authorization header that contains a Base64 encoded version of the following string: <shopperUserID>:<shopperPassword>. (Don’t forget to replace <shopperUserID> and <shopperPassword> with actual values before encoding the string.)
   • Example header value: Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW.
   • Required query parameters: code_challenge, usid, channel_id, client_id, and redirect_uri.

4. The SLAS API validates the user credentials, redirects to the redirect URI, and returns an authorization code.

5. The shopping app makes a request to the /token endpoint of the SLAS API.

   • The request must include an authorization header that contains a Base64 encoded version of the following string: <clientID>:<clientSecret>. (Don’t forget to replace <clientID> and <clientSecret> with actual values before encoding the string.)
   • Example header value: Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW.
   • The client ID and client secret must be provisioned for the app by a SLAS Organization Administrator. See the SLAS Admin API for more information.
   • Required query parameters: grant_type=authorization_code_pkce, code_verifier, code, client_id, and redirect_uri.

6. The endpoint responds with an access token in the form of a JSON Web Token (JWT), a customer_id string, a USID, and a refresh token.

   • The response also includes an enc_user_id string that can be used to call Einstein APIs.

7. The shopper adds a product to their basket.

8. The shopping app makes a request to the /baskets endpoint of OCAPI and provides a SLAS access token in the header.

9. The Baskets API saves a shopping basket with a customer_id string that is associated with the registered user.

Strict Client Auth is an optional setting for private clients, which requires all /login and /authorize requests to pass their credentials directly in the x-slas-client-auth header. This feature is part of a broader set of protections to help keep authentication endpoints secure and resilient against automated threats. Public clients don't support Strict Client Auth and ignore the x-slas-client-auth header if present.

To use this feature, turn on Strict Client Auth for a new or existing private client.

To review how Strict Client Auth interacts with the x-slas-client-auth header, expand the Strict Client Auth Behavior Matrix dropdown.

Then, make sure to include a valid x-slas-client-auth header on requests to /login and /authorize endpoints. Requests that don't include the header or include an invalid header return a 401 Unauthorized error. The header value must be a Base64-encoded string in the format client_id:client_secret.

SLAS validates the header against these criteria.

• The header value must be valid Base64.
• The decoded value must follow client_id:client_secret format with both values present.
• The client_id in the header must match the client_id query parameter.
• The client_secret must match the provisioned secret for the client.

Now that you’re familiar with the use cases with private clients, check out the Public SLAS Client Use Cases.

When you’re ready to incorporate SLAS into your app, explore the API reference for the complete technical specifications for the SLAS endpoints.