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).

The following IDPs are supported by SLAS:

Active Directory Federated Service"name": "adfs"
Amazon Cognito"name": "cognito"
Apple"name": "apple"
Auth0"name": "auth0"
Azure Active Directory"name": "azure"
Azure Active Directory B2C"name": "azure_adb2c"
Facebook"name": "facebook"
Forgerock"name": "forgerock"
Google"name": "google"
Okta"name": "okta"
Ping Identity"name": "ping"
Salesforce"name": "salesforce"
SAP Gigya"name": "gigya"

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".

To request support for an IDP that isn’t on the list, create a support ticket with Commerce Cloud. We can then work with you to configure the IDP.

We only support IDPs that are compliant with OpenID Connect. We don’t support SAML.

To set up any of the supported IDPs for SLAS, make a request to the idps endpoint of the SLAS Admin API. Make sure that you have set up a client ID with the IDP before making your request.

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.

To enable single sign-on, SLAS must be configured as an authentication provider on core Salesforce clouds. For more information, see this course on Trailhead: Set Up Social Sign-On.

When a shopper logs in through an IDP, a customer record specific to that IDP is created. For example, if 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).

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

Here’s an example request to set up Google as an IDP for SLAS. Don’t forget to replace {{idp_name}} with one of the supported IDP names listed earlier.

The value for redirectUrl in the request follows a different URL format than the endpoint.

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:{{idp_name}}https://{{short_code}}{{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.