SLAS Identity Providers

To support logging in with social media accounts or other federated login systems (Google’s, for example), you must set up an external identity provider (IDP) for SLAS.

When using an IDP, shopper credentials are stored in the external identity system, instead of the B2C Commerce. Using IDPs is optional. You can still use SLAS for implementing login and API access for shoppers whose credentials are stored in the B2C Commerce system as well (not the external IDP).

When a shopper logs in through an IDP, a customer record related to that IDP is created. For example, if rachel.rodriquez@example.com logs in first using Google and second using Facebook, two separate customer records are created. If Rachel logs in with Google, makes a purchase, and then logs in with Facebook, they can’t see the purchase that they made while logged in with Google. To see the purchase again, they must log in with Google (not Facebook).

To set up a supported IDP, first create an OAuth client in the IDP's administration portal. Next, use the SLAS Admin UI or SLAS Admin API to configure the IDP for a SLAS tenant.

You can set up more than one IDP for a tenant. For example, you could set up both Google and Facebook as IDPs for the same tenant.

Here’s an example request to set up Google as an IDP using the SLAS Admin API registerIdentityProvider endpoint:

  • name's value must be prefixed with an identifier for a supported IDP. You can append a - to the prefix followed by a string to create variations. For example, you can use google google-test , but not googletest".
  • redirectUrl follows a specific format.
  • The IDP uses the redirectUrl to redirect back to SLAS so that the shopper can stay logged in and a SLAS authorization code is created.
  • By default, SLAS uses client_secret_basic authentication to interact with the IDP. To change the method to client_secret_post provide isClientCredsBody: true in the request body.

To log a shopper in with an IDP, follow federated login flows detailed in the public or private use cases guides.

An example of a public client flow is shown below using the authorizeCustomer and getAccessToken endpoints:

If the shopper does not successfully authenticate or cancels the authentication, the browser is sent to the redirect URI with the details of the error in the query string.

Calling the SLAS logoutCustomer endpoint does not log the customer out of a third-party IDP. The customer must explicitly log out from the IDP.

Some IDPs, notably Google, display the redirect URL (or part of the redirect URL) on the OAuth consent screen.

To customize the redirect URL so that it includes your domain:

  1. On a branded domain, configure a reverse proxy to proxy the SLAS IDP callback URL. For example: https://auth.example.com/slas-callback/{{idp_name}} → https://$SHORT_CODE.api.commercecloud.salesforce.com/shopper/auth/v1/idp/callback/$IDP_NAME.
  2. Configure the IDP’s OAuth client to include the reverse proxy URL as an allowed callback URL.
  3. Configure your SLAS IDP settings to use the reverse proxy URL for the redirectUrl parameter. You can register a new IDP or update an existing one using either the registerIdentityProvider endpoint of the SLAS Admin API or the IDP page of the SLAS Admin UI.

If you are a PWA Kit developer, you can skip the step of configuring a reverse proxy. (You still must do the other two configuration steps described earlier.) By default, PWA Kit projects are already configured to use Managed Runtime’s reverse proxy to forward requests with /mobify/proxy/api/ in the path to the B2C Commerce API. A SLAS IDP callback URL in a PWA Kit project looks like this:

For more information on proxying with PWA Kit and Managed Runtime, see Proxy Requests.

The following IDPs are natively supported by SLAS:

SLAS only supports IDPs that support OpenID Connect. SLAS does not support SAML.

Use SLAS' default IDP functionality to configure other IDPs.

Configuring Apple as an IDP requires additional configuration:

  • The authUrl must be https://appleid.apple.com/auth/authorize?response_mode=form_post.
  • The client secret must be the Apple application private key. From the Apple Developer Dashboard under Certificates IDs & Profiles select Keys. Select the key to be used with SLAS and download its .p8 file. Use the value between -----BEGIN PRIVATE KEY----- and ----END PRIVATE KEY----- as the client secret.
  • Provide the Key ID obtained from Apple when you created your private key for client authentication. This value is also in the Apple Developer Dashboard under Certificates IDs & Profiles under Keys.
  • Provide your Apple Team ID.

Here’s an example request to set up Apple as an IDP using the SLAS Admin API registerIdentityProvider endpoint: