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

When you are only using 3rd party identity providers (IDPs) for SLAS authentication, you can configure a SLAS client ID to block access to the SLAS /login endpoint, which is not needed for 3rd party IDP workflows.

To block the use of the /login endpoint, set the loginEpRestrict parameter to true (enabled) when configuring the SLAS client ID in the SLAS Admin UI. For security reasons, when loginEpRestrict is set to true (enabled), calls to the /login endpoint return a 403 Forbidden code.

To allow access to the SLAS /login endpoint, you can do either of the following actions:

  • Configure a separate SLAS client ID that does not have loginEpRestrict enabled.
  • Disable the the loginEpRestrict parameter.

By default, loginEpRestrict is set to false(not enabled), which allows SLAS /login endpoint calls to be processed.

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.

For auth code flows with 3rd parties, SLAS allows for the addition of query parameters to the SLAS /authorize endpoint that can be passed through to the 3rd party IDP /authorize endpoint.

SLAS looks for the 3rd party authorization parameters that have a prefix of “c_”. When present, SLAS passes these through to the 3rd party IDP /authorize endpoint.

  • SLAS looks for query params that begin with “c_”, for example:
    • c_auth0_state=a495d731-66a1-4e0b-9b57-b9fa4adca2cc&c_parm2,
  • SLAS removes the “c_” prefix and add the key value pairs to the 3rd party IDP /authorize URI as query parameters, for example:
    • ...auth0/authorize&auth0_state=a495d731-66a1-4e0b-9b57-b9fa4adca2cc,&param2=jakku&scope=offline email...
  • SLAS validates the 3rd party IDP /authorize endpoint query parameters:
    • Values missing from the key value pair will drop the query parameter from being added.
    • Total character length of all 3rd party IDP /authorize endpoint query parameters cannot exceed 2K.

Call flow with custom parameters

  1. A Web, SPA, or Mobile app or a BFF calls the SLAS /authorize endpoint.
  2. The call includes the OAuth STATE param and NEW customer parameters denoted with c_.
  3. SLAS saves the CALLER_STATE and returns it later via a redirect.
  4. SLAS calls the downstream IDP /authorize endpoint as part of an SSO flow. The call includes the SLAS_STATE value and the custom parameters provided to SLAS in the first step.
  5. The IDP performs the authentication call.
  6. The IDP returns the SLAS_STATE in a redirect call.
  7. SLAS pulls the CALLER_STATE from its backing store.
  8. SLAS returns the CALLER_STATE in the redirect back to the original caller.

Example cUrl command to SLAS with an IDP state variable c_auth0_state:

SLAS then creates the location header for the call to the 3rd-party IDP’s /authorize endpoint:

The previous call results in a callback to SLAS from the IDP with 8fb24a51-d4cc-42bd-af02-7c1740a1448c preserved per the OIDC spec.

Neither custom parameters nor custom parameters values are returned to redirect_uri when authentication is complete.

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: