Configure authentication providers and single sign-on (SSO)

By default, StoreConnect provides username + password login for store customers. To offer other login methods, you configure an Authentication Provider for each one you want to enable.

Supported authentication providers:

• StoreConnect (username + password)
• Azure Active Directory B2C
• Google
• Microsoft Entra ID
• SAML (any SAML 2.0 identity provider — Okta, OneLogin, PingFederate, and others)
• Experience Cloud

Configure authentication providers

Each authentication provider is configured as an Authentication Provider record on your store. Unless you only allow username + password login, you need one record for every provider you want to enable.

To add a provider record:

1. Go to your store record.
2. Select Additional Relationships.
3. Scroll to the Authentication Providers section.
4. Select New.

Then set the fields for the provider you are adding, as described in the sections below.

StoreConnect authentication (username + password)

If no active authentication providers exist for a store, username + password login is available by default — you don’t need a record for it.

To offer alternative login options and keep username + password login, add a StoreConnect Authentication Provider record. Select StoreConnect Username / Password in the Provider field, select Active, and leave all other fields blank.

StoreConnect Field	Value
Provider	StoreConnect Username / Password
Authorised Domains
Client Id
Client Secret
Provider URL
Reset Password URL

Azure Active Directory B2C authentication

Complete the fields as follows.

StoreConnect Field	Value
Provider	Azure ActiveDirectory B2C
Authorised Domains
Client Id	Azure Client ID
Client Secret
Provider URL	Azure Base URL
Reset Password URL

The Base URL here is the URL of your Azure login page, it may be similar to: https://<tenant>.b2clogin.com/<tenant>.onmicrosoft.com/B2C_1A_signup_signin

To test if your URL is correct you should be able to add /discovery/keys to the end of the URL and visit it in a browser. If the URL is correct you should see a JSON response similar to:

```json

{ “keys”: [ {“kid”:”EU323HFCv3ZRmOgTOGLXcFsjlnq0RzRhzKsSGFXLDyk3”,”use”:”sig”,”kty”:”RSA”,”e”:”AQAB”,”n”:”…”} ] } ```

Callback URL

In your Active Directory configuration you will need to add the callback URL to the list of permitted URLs:

https://your-store-domain/logins/auth/azure/callback

Reset Password URL

Set this field to the identity provider’s own password reset page. The store’s reset password flow then redirects the customer there. See Password reset and password changes for SSO accounts for how this works and what customers see if it is left blank.

Azure AD payload mapping

When StoreConnect receives a token from Azure AD, it maps the payload fields to Contact fields as follows:

Azure AD payload field	Salesforce Contact field
sub	sso_uid
(provider name, e.g. azure)	sso_provider
email || signInName || signInNames.emailAddress || upn || preferred_username	email, username
given_name	first_name
family_name	last_name
phone_number || Phone Number	phone
name	Account name

|| indicates priority order — the first present value is used.

Capturing additional Azure claims

The payload mapping above is fixed. StoreConnect does not support adding new fields to it from the administration panel. To capture additional claims from the Azure token, such as a customer’s date of birth, override the provider’s callback controller with a Liquid after block that writes the claim to a custom field.

1. Create a theme template with the key controllers/omniauth/azure.
2. Add an after block that reads the claim from session_variables.auth_data.id_token_claims and writes it using the update tag:

liquid {% liquid after update current_customer, field: "date_of_birth__c", value: session_variables.auth_data.id_token_claims.extension_DateOfBirth endafter %}

Replace `extension_DateOfBirth` with the exact claim name your Azure tenant returns. `session_variables.auth_data.id_token_claims` contains the full token payload, so any claim sent by your identity provider is available here.

1. Create a Custom Data Mapping for the target field with Read/Write access. The value will not save without it. See Add custom data fields to your store for full setup details.
2. If your org uses Person Accounts and the field is a Contact field, map the corresponding __pc field on Account (for example date_of_birth__pc) instead of the __c field on Contact.

:::note This only captures claims present in the ID token returned through the SSO redirect flow. Fields collected by a custom Azure B2C sign-up/sign-in policy are only available here if that policy is configured to return them as ID token claims. :::

Google authentication

Complete the fields as follows.

StoreConnect Field	Value
Provider	Google
Authorised Domains
Client Id	Google OAuth Client ID
Client Secret	Google OAuth Client Secret
Provider URL
Reset Password URL

To generate your credentials, follow these instructions from Google: OAuth Access

Reset Password URL

Set this field to the identity provider’s own password reset page. For Google, use https://support.google.com/mail/answer/41078 to direct customers to Google’s own support page. See Password reset and password changes for SSO accounts for how this works and what customers see if it is left blank.

Microsoft Entra ID authentication

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft’s workforce identity service. Use this provider when your customers or staff authenticate with Microsoft 365 / work accounts.

:::note This provider is for standard Microsoft Entra ID (workforce edition). If you are using Azure Active Directory B2C — the consumer-facing identity service with custom sign-up/sign-in policies — refer to the Azure Active Directory B2C authentication provider procedure instead. :::

StoreConnect Field	Value
Provider	Microsoft Entra ID
Authorised Domains
Client Id	Azure Application (client) ID
Client Secret	Azure client secret value
Provider URL	https://login.microsoftonline.com/<tenant-id>
Reset Password URL

Replace <tenant-id> with your Azure tenant ID — a UUID visible in the Azure portal under Microsoft Entra ID → Overview.

To verify that the Provider URL is correct, append /discovery/keys?appid=<your-client-id> to the URL and open it in a browser. You should see a JSON response listing signing keys:

```json

{ “keys”: [ {“kid”:”…”,”use”:”sig”,”kty”:”RSA”,”e”:”AQAB”,”n”:”…”} ] } ```

Registering the app in Azure

In the Azure portal, register a new app under Microsoft Entra ID, with the following configured:

1. Set the redirect URI (platform: Web) to the callback URL below.
2. Generate a client secret under Certificates & secrets, and copy the secret value (not the secret ID) into the Client Secret field.
3. Under API permissions, confirm that openid and email delegated permissions are granted.

Callback URL

Add the following redirect URI to your Azure app registration:

https://your-store-domain/logins/auth/entra_id/callback

Reset Password URL

Set this field to the identity provider’s own password reset page. For Microsoft accounts you can use your organization’s self-service password reset URL, or leave it blank if password management is handled by your IT team. See Password reset and password changes for SSO accounts for how this works and what customers see if it is left blank.

Entra ID payload mapping

Microsoft Entra ID uses the same token claim mapping as Azure AD B2C. See Azure AD payload mapping.

Capturing additional Entra ID claims

Entra ID uses the same claim capture mechanism as Azure AD B2C. Override the callback controller for this provider (theme template key controllers/omniauth/entra_id) and write claims to custom fields with an after block. See Capturing additional Azure claims for the full steps.

SAML authentication

To configure a SAML 2.0 identity provider such as Okta, OneLogin, or PingFederate, follow the dedicated Set up SAML single sign-on guide. It covers adding the SAML value to the Provider picklist, creating the Authentication Provider record, and configuring your identity provider.

Experience Cloud authentication

Experience Cloud requires more Salesforce configuration than the other providers. Follow the dedicated Experience Cloud login as SSO guide.

Password reset and password changes for SSO accounts

When a customer’s account is tied to an SSO Authentication Provider — any provider other than StoreConnect username/password — StoreConnect intentionally hands password and username management to the identity provider. The customer signs in through the identity provider, and their password and username cannot be reset or changed inside StoreConnect. This is by design, not an error.

This affects two situations:

A customer requests a password reset on the store

• If the provider has a Reset Password URL set, StoreConnect redirects the customer to that URL — the identity provider’s own password reset page.
• If the provider has no Reset Password URL, StoreConnect displays: “Password reset is not supported for this account. Please contact support for assistance.”

A reset link is sent from Salesforce

Even when a reset link is generated and sent — for example, by an admin from Salesforce — an SSO customer who follows it and tries to save a new password sees “can’t be changed” beneath the password field. Passwords are immutable for SSO accounts, and the customer’s username is immutable for the same reason.

:::note In the default theme, the “reset password” link is always shown on the login page, so SSO customers can reach the reset flow and see the “not supported” message. The current_store.sso_reset_password? Liquid property returns true only when a provider allows password resets. Use it in a custom theme to hide the link, or to show SSO customers a message directing them to sign in through their identity provider instead. :::

To give SSO customers a working reset link, set the Reset Password URL on the Authentication Provider record to the identity provider’s own password reset page.

When a username+pasword account becomes an SSO account

If a customer who originally registered with a username and password starts to sign in with SSO, they become an SSO managed account from then on. The moment they sign in through an identity provider — even once — from that point on, their account behaves exactly like an SSO-created account. This means password reset is blocked (or redirected to the Reset Password URL, if one is set), and the password and username can no longer be changed inside StoreConnect.

This change is permanent. There is no store or Salesforce setting that converts the account back to password managed. The customer’s original password still works to sign in directly, but it can no longer be reset or changed.

:::warning Advise customers who have logged in with SSO to keep using SSO to sign in. If they need a working password reset path, set the Reset Password URL on the Authentication Provider so the store’s forgot-password flow sends them to the identity provider’s own reset page. :::

Password fields on the account page when SSO is enabled

Once a store has any active SSO provider, the default theme hides the Current Password, New Password, and Confirm New Password fields — and disables the username field — under Account > Login Details for every customer. Only the email field remains visible. This applies to all customers, including those who registered with a username and password and have never used SSO.

If you want password-only customers to keep a working password-change form while a store also offers SSO, override the account/credentials.liquid snippet in a custom theme and gate the password fields on the individual customer instead of the store. The customer.sso_provider Liquid property is blank for customers who sign in with a username and password, and set to the provider name for SSO customers, so you can show the fields only when it is blank.

Details on a new contact

When a new website account is created using an SSO provider, these values are saved on the new Contact record:

SSO Provider field	Salesforce Contact field
First Name	First Name
Last Name	Last Name
Email	Username
Email	Email
Phone	Phone

How StoreConnect links SSO identities to contacts

When a customer authenticates via SSO, StoreConnect links their identity provider account to a Salesforce Contact record. Understanding this flow helps with troubleshooting linking issues and designing the right login UX for your store.

The redirect flow

1. Customer clicks the login button on the store.
2. StoreConnect redirects to the identity provider (e.g. Azure AD), passing a provider_id that identifies which provider record to use.
3. The customer authenticates with the identity provider.
4. The identity provider redirects back to StoreConnect’s callback URL.
5. StoreConnect validates the identity and links it to a contact.

What StoreConnect captures: email, first name, last name, phone, and the provider’s unique user ID. These are stored on the Contact and Login records.

What StoreConnect cannot capture: if a customer creates an identity provider account independently — outside of the StoreConnect login redirect flow — StoreConnect has no way to link it to a contact. The link is only established when the customer authenticates through StoreConnect’s redirect flow.

How StoreConnect matches returning users to contacts

When a customer returns through the SSO redirect, StoreConnect attempts to match them to an existing contact in this order:

1. Post-checkout session — if the customer just completed checkout in the same browser session, StoreConnect uses the contact created at checkout directly. Most reliable.
2. Previously linked SSO identity — if the customer has logged in via SSO before, StoreConnect matches by their stored provider user ID.
3. Email address — StoreConnect performs a case-insensitive email match against existing contacts, returning the most recently created match.

If no match is found, StoreConnect creates a new contact.

Post-checkout SSO account creation

A common scenario in B2B stores: a customer completes checkout as a guest — creating a contact in Salesforce — but hasn’t yet linked an SSO account. StoreConnect can link their SSO identity to that contact, but how it links depends on whether the customer is still in the same browser session.

Link during the same session (most reliable)

When a customer reaches the order confirmation page, StoreConnect stores the contact created at checkout in their session. If the customer then signs in with SSO from that page — in the same session — StoreConnect links the SSO identity directly to that contact, with no email matching involved.

To support this, show the store’s SSO login options on the order confirmation page so the customer can sign in before they leave. SSO is initiated by submitting the storefront’s SSO login form, which posts to:

/logins/auth/<provider>?provider_id=<AUTHENTICATION_PROVIDER_SFID>

Here <provider> is the provider identifier (for example azure) and AUTHENTICATION_PROVIDER_SFID is the Salesforce ID of the store’s Authentication Provider record.

:::warning SSO login must be triggered by the storefront SSO form, which submits a POST request with a CSRF token. A plain link or redirect to this URL — for example in an email — will not start the flow. The session that holds the checkout contact also only exists in the customer’s browser, so post-checkout linking has to happen on the order confirmation page while the customer is still in that session. :::

Link on a later visit

If the customer leaves without linking and signs in with SSO later, StoreConnect falls back to matching them by email address (see How StoreConnect matches returning users to contacts).

Note: email matching returns the most recently created contact with that email address. If a customer has duplicate Contact records in Salesforce, StoreConnect may link to the wrong one. Resolve duplicate contacts before relying on this approach.

Logout behavior

When a customer clicks logout, StoreConnect always clears its own session. Whether the identity provider (IdP) session is also terminated depends on the provider configured for your store.

Providers where the IdP session is also ended

SingleKey ID — StoreConnect redirects to the SingleKey end-session endpoint on logout, which terminates the customer’s SingleKey session. The customer must authenticate again on their next login.

Providers where only the StoreConnect session is cleared

For Azure AD B2C, Microsoft Entra ID, Google, and generic OpenID providers, StoreConnect clears its own session but does not contact the identity provider’s end-session endpoint.

What this means for Azure AD B2C and Entra ID: the customer’s Azure session cookie remains active in their browser after they log out of StoreConnect. If they click login again, Azure may silently re-authenticate them without prompting for credentials — it can appear as though logout had no effect.

If your store requires a full sign-out from Microsoft on logout — for example, on shared or public devices — inform customers they should also sign out from their Microsoft account directly, or close their browser entirely.