SLAS Trusted System on Behalf Authorization

Trusted System on Behalf (TSOB) is a login flow designed for system to system communication in back office workflows, for example:

  • You want all logins to route through your external IDP and don’t want customers to login with SLAS.
  • You want to take action as a system on behalf of a shopper.

TSOB authentication uses the getTrustedSystemAccessToken endpoint, which requires a SLAS private client with the sfcc.ts_ext_on_behalf_of scope. For details, see the Authorization Scopes Catalog.

  • TSOB is not the preferred method for Shopper authentication flows as it is outside the OAuth and OIDC standard. For the most secure authentication mechanism, use one of the workflows described in Shopper Login public and private use cases. Do not use TSOB if shopper information frequently changes and idp_origin=ecom, as TSOB will not retrieve the most up-to-date customer information from B2C Commerce.
  • As part of our bot mitigation strategy for the upcoming holiday season, SLAS Trusted System on Behalf (TSOB) login will have a service protection window of 3 seconds.
    • Beginning 10/02/2024 in the AP-Northeast-1 region and 10/09/2024 in the US-East-1 region, customers attempting to log in more than once through TSOB during a period of 3 seconds will receive a 409 HTTP error. No customer impact is anticipated. If you see an increase in 409 HTTP errors, open a support case.
    • No change is planned for the SLAS AP-Southeast-2 and EU-Central-1 regions, which are already configured for 3 seconds.

Each shopper is associated with a unique login_id. You must use the shopper's unique login_id for each interaction with that shopper. Otherwise, multiple shopper records are created in SLAS and B2C Commerce. If a new login_id is passed in for TSOB using an IDP, a new shopper is created.

Each USID is a unique shopper ID that is created for a specific shopper's session. After a USID is created, you can use it across that shopper's interactions. The SLAS client API application (SPA, Mobile, Composable, etc.) handles the USID, which must be saved by the client API app and used as needed when making SLAS API calls.

TSOB using an IDP, for example: Google, does not make a call to the IDP for user verification, because SLAS performs checks to verify a user is valid. Using the SLAS /authorize endpoint provides the strongest validation from the IDP.

All TSOB flows require a SLAS private client id and secret to be in an Authorization header.

To request a guest shopper TSOB token:

Provide body parameters idp_origin=ecom and login_id=guest.

To request a registered shopper TSOB token:

Provide body parameters idp_origin=ecom and login_id, whose value is the login of an existing registered shopper.

If the shopper does not exist, SLAS returns an HTTP 400:

To request a TSOB token for a shopper registered through an external IDP:

Provide body parameters idp_origin, whose value is the ID of the IDP and login_id, whose value is the shopper login.

If the shopper record does not exist, SLAS creates it. The shopper's login_id, first_name, and last_name as set to the value provided. SLAS does not communicate with the IDP to get the shopper information.

TSOB returns a TokenResponse, including a SLAS TSOB access token for the shopper and a refresh token. The refresh token can be used with the getAccessToken endpoint to obtain a new TSOB access token.

When an access_token is refreshed, the new token's TTL is reset. The refresh token's TTL is also reset.

A TSOB access tokens include the tsob:ts_ext_on_behalf_of type in the isb sub-claim.

To protect against overuse, if multiple calls for the same shopper are made in succession, SLAS returns an HTTP 409: