SLAS Best Practices

Follow best practices for the Shopper Login and API Access Service (SLAS) to maximize security and performance. Recommended steps include using Strict Client Auth for private clients and rotating a guest shopper’s session after they place an order.

Strict Client Auth

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.

1x-slas-client-auth: Base64(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.

SLAS validates the x-slas-client-auth header whenever it’s included in the request, regardless of whether the client has Strict Client Auth turned on.

Note

Mitigate Guest Token Reuse

Prevent guest order data from appearing in a shopper’s registered account by rotating the guest session immediately after receiving a guest order. Treat every completed guest order as a session boundary. In the recommended flow, after order confirmation, request a fresh guest token from SLAS using grant_type=client_credentials. Then, replace the currently stored access token and refresh token with the new ones.

If a guest later registers on the same device, the registered profile has no association with prior guest orders. By isolating guest sessions, you enable privacy-first guest shopping on retail kiosks, public computers, and shared devices where multiple guest shoppers browse and checkout sequentially.

Recommended Guest Token Flow

Sequence diagram showing guest token rotation flow with order placement, session rotation, and later registration

The recommended flow triggers upon order confirmation, when a POST /orders request succeeds (1).

Ideally, make order confirmation the trigger for session rotation. This step marks the strongest boundary for guest shopper activity.
Alternatively, use these trigger points, in order of preference:

After payment completion, if using a multi-step checkout with deferred order creation.
On logout. SLAS already handles this via /logout. However, this trigger doesn’t help if the guest never explicitly logs out before registering.

Note

Session Rotation Step 1: Get a Fresh Guest Token

Send a POST request to /token with grant_type set to client_credentials (2). Passing the client credentials allows the client application to get access and refresh tokens for guest user through a trusted server. For more information, see getAccessToken.

1POST /shopper/auth/v1/organizations/{organizationId}/oauth2/token
2Content-Type: application/x-www-form-urlencoded
3grant_type=client_credentials&channel_id={siteId}

The response includes a new access_token and refresh_token.

Session Rotation Step 2: Swap Tokens in the Storefront

Replace the stored access_token and refresh_token with the values returned in Step 1 (3). All subsequent B2C Commerce API calls use the new session.

Result: Empty Order List Following Account Registration

The benefit of session rotation shows up if the guest shopper subsequently registers an account (4). The previous guest order data doesn’t appear in the registered account profile.

To demonstrate this result, the sequence diagram shows that after registering an account and authorizing a new session, calling getCustomerOrders returns an empty order list.

Edge Cases to Consider

When implementing a session rotation flow for guest tokens, keep these edge cases in mind.

Scenario	Recommendation
Guest places multiple orders in one session	Rotate after each order, or at minimum after the last order before the session ends.
Guest refreshes page between revoke and new token	Treat revoke+new-token as an atomic operation (no user-visible gap).
Guest has items in cart when session rotates	Transfer the basket to the new session if needed, or perform the rotation only after checkout completes (cart is empty). Cart is managed by the Shopper Baskets API, keyed by `customer_id.`
Public client without `client_secret`	Use `token_type_hint=refresh_token` with the refresh token in the revoke call; for the new guest token, use `client_credentials` with Proof Key for Code Exchange (PKCE) if required by the client configuration.
Session Bridge (SESB/hybrid) flows	Rotate before the session bridge, not after. SESB flows intentionally preserve guest context across the bridge.