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, the source of truth for shopper credentials is the external identity system, instead of the B2C Commerce system. Setting up 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 specific 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).

The following IDPs are supported by SLAS:

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 with 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:

• You must use one of the strings from the list of supported IDPs for the value of the name property in the JSON object that you use in the body of your API requests. You can also append - to the IDP name, followed by any string to create variations. For example, you can use both "name": "google" and "name": "google-test", but not "name": "googletest".
• The value for redirectUrl in the request follows specific format.

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.

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: