{"title":"Configure authentication providers and single sign-on (SSO)","slug":"authentication-providers","url":"https://support.storeconnect.com/articles/authentication-providers","url_markdown":"https://support.storeconnect.com/articles/authentication-providers.md","subtitle":null,"summary":"Configure store login options including username/password, Azure Active Directory B2C, Microsoft Entra ID, Google OAuth, and Experience Cloud SSO by creating Authentication Provider records.","type":"Help_Documentation","video_url":"","keywords":"authentication, single sign-on, SSO, login, sign in, authentication provider, Azure Active Directory, Azure AD, Google OAuth, Experience Cloud, username password, OAuth, identity provider, login methods, store login, callback URL, OpenID Connect, access control, federated identity, social login, multi-provider, SAML, SAML 2.0, Okta, OneLogin, PingFederate, metadata URL, assertion consumer service, ACS, entity ID","last_modified":"2026-08-21T07:12:35+0000","body_markdown":"Use this process to set up the login methods your store customers use. By default StoreConnect offers username and password login. To offer anything else, you create an **Authentication Provider** record for each method you want to enable.\n\n## Choose your providers\n\nStoreConnect supports these providers. Two of them have their own articles because they need more configuration than a single record.\n\n| Provider | Use it when | Where to configure it |\n|---|---|---|\n| StoreConnect (username and password) | You want customers to register directly on your store | This article |\n| Azure Active Directory B2C | Your customers sign in with a consumer identity managed in Azure AD B2C | This article |\n| Microsoft Entra ID | Your customers or staff sign in with Microsoft 365 or work accounts | This article |\n| Google | You want Google sign-in | This article |\n| SAML | You run any SAML 2.0 identity provider, such as Okta, OneLogin, or PingFederate | [Set up SAML single sign-on](saml-single-sign-on) |\n| Experience Cloud | Your customers already have Experience Cloud logins | [Use Experience Cloud login as SSO](experience-cloud-login) |\n\nYou can enable more than one provider on a store. Each one needs its own record.\n\n:::warning\nOnce a customer signs in through any SSO provider, even once, their account becomes SSO managed permanently and their password can no longer be reset or changed inside StoreConnect. Read [password reset and password changes for SSO accounts](#password-reset-and-password-changes-for-sso-accounts) before you enable SSO on a store that already has password customers.\n:::\n\n## Before you begin\n\n- You need access to edit the **Store** record in Salesforce.\n- Have the credentials from your identity provider ready. Which ones depend on the provider: most need a client ID and client secret, SAML needs a metadata URL.\n- Decide whether you are keeping username and password login alongside SSO. If you are, you need a record for that too, as described below.\n\n## Create an Authentication Provider record\n\nEvery provider starts the same way. Create the record, then set the fields for your provider using the tables further down.\n\n1. On the **Store** record, go to **Additional Relationships** \u003e **Authentication Providers**.\n2. Select **New**.\n3. Set the fields for the provider you are adding, as described in the sections below.\n4. Select **Active**, then save the record.\n5. Confirm the provider works: open your store in a private browser window and check that the new login option appears on the login page and completes a sign-in.\n\n## StoreConnect authentication (username and password)\n\nIf no active authentication providers exist for a store, username and password login is available by default. You do not need a record for it.\n\nTo offer other login options *and* keep username and password login, add a StoreConnect **Authentication Provider** record. Select **StoreConnect Username / Password** in the **Provider** field, select **Active**, and leave all other fields blank.\n\n| StoreConnect Field | Value                            |\n|--------------------|----------------------------------|\n| Provider           | StoreConnect Username / Password |\n| Authorised Domains |                                  |\n| Client Id          |                                  |\n| Client Secret      |                                  |\n| Provider URL       |                                  |\n| Reset Password URL |                                  |\n\n## Azure Active Directory B2C authentication\n\nComplete the fields as follows.\n\n| StoreConnect Field | Value                     |\n|--------------------|---------------------------|\n| Provider           | Azure ActiveDirectory B2C |\n| Authorised Domains |                      |\n| Client Id          | Azure Client ID      |\n| Client Secret      |                      |\n| Provider URL       | Azure Base URL       |\n| Reset Password URL |                      |\n\nThe Base URL here is the URL of your Azure login page, it may be similar to: `https://\u003ctenant\u003e.b2clogin.com/\u003ctenant\u003e.onmicrosoft.com/B2C_1A_signup_signin`\n\nTo 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:\n\n```json\n\n{ \"keys\": [ {\"kid\":\"EU323HFCv3ZRmOgTOGLXcFsjlnq0RzRhzKsSGFXLDyk3\",\"use\":\"sig\",\"kty\":\"RSA\",\"e\":\"AQAB\",\"n\":\"...\"} ] }\n```\n\n### Callback URL\n\nIn your Active Directory configuration you will need to add the callback URL to the list of permitted URLs:\n\n```\nhttps://your-store-domain/logins/auth/azure/callback\n```\n\n### Reset Password URL\n\nSet 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](#password-reset-and-password-changes-for-sso-accounts) for how this works and what customers see if it is left blank.\n\n### Azure AD payload mapping\n\nWhen StoreConnect receives a token from Azure AD, it maps the payload fields to Contact fields as follows:\n\n| Azure AD payload field | Salesforce Contact field |\n|------------------------|--------------------------|\n| `sub` | `sso_uid` |\n| (provider name, e.g. `azure`) | `sso_provider` |\n| `email` \\|\\| `signInName` \\|\\| `signInNames.emailAddress` \\|\\| `upn` \\|\\| `preferred_username` | `email`, `username` |\n| `given_name` | `first_name` |\n| `family_name` | `last_name` |\n| `phone_number` \\|\\| `Phone Number` | `phone` |\n| `name` | Account `name` |\n\n`||` indicates priority order; the first present value is used.\n\n### Capturing additional Azure claims\n\nThe 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.\n\n1. Create a theme template with the key `controllers/omniauth/azure`.\n2. Add an `after` block that reads the claim from `session_variables.auth_data.id_token_claims` and writes it using the `update` tag:\n\n    \n```liquid\n    {% liquid\n      after\n        update current_customer, field: \"date_of_birth__c\", value: session_variables.auth_data.id_token_claims.extension_DateOfBirth\n      endafter\n    %}\n    ```\n\n\n    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.\n\n3. 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](liquid-custom-data-fields) for full setup details.\n4. 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.\n\n:::note\nThis 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.\n:::\n\n## Google authentication\n\nComplete the fields as follows.\n\n| StoreConnect Field | Value                      |\n|--------------------|----------------------------|\n| Provider           | Google                     |\n| Authorised Domains |                            |\n| Client Id          | Google OAuth Client ID     |\n| Client Secret      | Google OAuth Client Secret |\n| Provider URL       |                            |\n| Reset Password URL |                            |\n\nTo generate your credentials, follow these instructions from Google: [OAuth Access](https://developers.google.com/identity/protocols/oauth2)\n\n### Reset Password URL\n\nSet 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](#password-reset-and-password-changes-for-sso-accounts) for how this works and what customers see if it is left blank.\n\n## Microsoft Entra ID authentication\n\nMicrosoft 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.\n\n:::note\nThis 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.\n:::\n\n| StoreConnect Field | Value |\n|--------------------|-------|\n| Provider           | Microsoft Entra ID |\n| Authorised Domains | |\n| Client Id          | Azure Application (client) ID |\n| Client Secret      | Azure client secret value |\n| Provider URL       | `https://login.microsoftonline.com/\u003ctenant-id\u003e` |\n| Reset Password URL | |\n\nReplace `\u003ctenant-id\u003e` with your Azure tenant ID, a UUID visible in the Azure portal under Microsoft Entra ID \u003e Overview.\n\nTo verify that the Provider URL is correct, append `/discovery/keys?appid=\u003cyour-client-id\u003e` to the URL and open it in a browser. You should see a JSON response listing signing keys:\n\n```json\n\n{ \"keys\": [ {\"kid\":\"...\",\"use\":\"sig\",\"kty\":\"RSA\",\"e\":\"AQAB\",\"n\":\"...\"} ] }\n```\n\n### Registering the app in Azure\n\nComplete these steps in the Azure portal before you save the StoreConnect record, because two of the values it needs are generated here.\n\n1. In the Azure portal, go to **Microsoft Entra ID** \u003e **App registrations** and register a new app.\n2. Set the redirect URI, with platform **Web**, to the callback URL below.\n3. Under **Certificates \u0026 secrets**, generate a client secret and copy the secret **Value**, not the **Secret ID**, into the **Client Secret** field on the StoreConnect record. The value is only shown once.\n4. Under **API permissions**, confirm the `openid` and `email` delegated permissions are granted.\n\n### Callback URL\n\nAdd the following redirect URI to your Azure app registration:\n\n```\nhttps://your-store-domain/logins/auth/entra_id/callback\n```\n\n### Reset Password URL\n\nSet 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](#password-reset-and-password-changes-for-sso-accounts) for how this works and what customers see if it is left blank.\n\n### Entra ID payload mapping\n\nMicrosoft Entra ID uses the same token claim mapping as Azure AD B2C. See [Azure AD payload mapping](#azure-ad-payload-mapping).\n\n### Capturing additional Entra ID claims\n\nEntra 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](#capturing-additional-azure-claims) for the full steps.\n\n## SAML authentication\n\nTo configure a SAML 2.0 identity provider such as Okta, OneLogin, or PingFederate, follow [set up SAML single sign-on](saml-single-sign-on). It covers adding the SAML value to the **Provider** picklist, creating the **Authentication Provider** record, and configuring your identity provider.\n\n## Experience Cloud authentication\n\nExperience Cloud requires more Salesforce configuration than the other providers. Follow [use Experience Cloud login as SSO](experience-cloud-login).\n\n## Password reset and password changes for SSO accounts\n\nWhen a customer's account is tied to an SSO **Authentication Provider** (any provider other than StoreConnect username and password), StoreConnect 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.\n\nThere is no store or Salesforce setting that overrides it. The only control you have is where the store sends customers who ask to reset.\n\nThis affects two situations:\n\n**A customer requests a password reset on the store**\n\n- If the provider has a **Reset Password URL** set, StoreConnect redirects the customer to that URL, which is the identity provider's own password reset page.\n- If the provider has no **Reset Password URL**, StoreConnect displays: \"Password reset is not supported for this account. Please contact support for assistance.\"\n\n**A reset link is sent from Salesforce**\n\nEven 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.\n\n:::note\nIn the default theme, the reset password link is always shown on the login page, so SSO customers 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.\n:::\n\nTo 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.\n\n### When a username and password account becomes an SSO account\n\nIf 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. From the moment they sign in through an identity provider, even once, 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.\n\nThis 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.\n\n:::warning\nAdvise customers who have signed in with SSO to keep using SSO. 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.\n:::\n\n### Password fields on the account page when SSO is enabled\n\nOnce 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** \u003e **Login Details** for every customer. Only the **Email** field stays visible. This applies to all customers, including those who registered with a username and password and have never used SSO.\n\nIf you want password-only customers to keep a working password-change form while the store also offers SSO, override the `account/credentials.liquid` snippet in a custom theme and gate the password fields on the individual customer rather than 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.\n\n## Contact fields set on a new SSO account\n\nWhen a new website account is created through an SSO provider, these values are saved on the new **Contact** record:\n\n| SSO provider field | Salesforce Contact field |\n|--------------------|--------------------------|\n| First Name         | **First Name**           |\n| Last Name          | **Last Name**            |\n| Email              | **Username**             |\n| Email              | **Email**                |\n| Phone              | **Phone**                |\n\n## How StoreConnect links SSO identities to contacts\n\nWhen a customer authenticates through SSO, StoreConnect links their identity provider account to a Salesforce **Contact** record. Knowing how that link is made helps you troubleshoot linking problems and design the right login experience for your store.\n\n### The redirect flow\n\n1. The customer selects the login button on the store.\n2. StoreConnect redirects to the identity provider (for example Azure AD), passing a `provider_id` that identifies which provider record to use.\n3. The customer authenticates with the identity provider.\n4. The identity provider redirects back to StoreConnect's callback URL.\n5. StoreConnect validates the identity and links it to a **Contact**.\n\n**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.\n\n**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.\n\n### How StoreConnect matches returning users to contacts\n\nWhen a customer returns through the SSO redirect, StoreConnect tries to match them to an existing **Contact** in this order:\n\n1. **Post-checkout session** — if the customer just completed checkout in the same browser session, StoreConnect uses the **Contact** created at checkout directly. This is the most reliable match.\n2. **Previously linked SSO identity** — if the customer has signed in through SSO before, StoreConnect matches on their stored provider user ID.\n3. **Email address** — StoreConnect performs a case-insensitive email match against existing contacts, returning the most recently created match.\n\nIf no match is found, StoreConnect creates a new **Contact**.\n\n## Post-checkout SSO account creation\n\nA common scenario in B2B stores: a customer completes checkout as a guest, creating a **Contact** in Salesforce, but has not 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.\n\n### Link during the same session (most reliable)\n\nWhen 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.\n\nTo 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:\n\n```\n/logins/auth/\u003cprovider\u003e?provider_id=\u003cAUTHENTICATION_PROVIDER_SFID\u003e\n```\n\nHere `\u003cprovider\u003e` is the provider identifier (for example `azure`) and `AUTHENTICATION_PROVIDER_SFID` is the Salesforce ID of the store's Authentication Provider record.\n\n:::warning\nSSO 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, does 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.\n:::\n\n### Link on a later visit\n\nIf 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](#how-storeconnect-matches-returning-users-to-contacts).\n\n:::warning\nEmail matching returns the most recently created **Contact** with that email address. If a customer has duplicate **Contact** records in Salesforce, StoreConnect can link the login to the wrong one. Resolve duplicate contacts before you rely on this approach.\n:::\n\n## Logout behavior\n\nWhen a customer selects logout, StoreConnect always clears its own session. Whether the identity provider (IdP) session also ends depends on the provider configured for your store. There is no setting that changes this; it is fixed per provider.\n\n### Providers where the IdP session is also ended\n\n- **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.\n\n### Providers where only the StoreConnect session is cleared\n\nFor **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.\n\n**What this means for Azure AD B2C and Entra ID:** the customer's Azure session cookie stays active in their browser after they log out of StoreConnect. If they select login again, Azure may silently re-authenticate them without prompting for credentials, so it can appear as though logout had no effect.\n\nIf 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."}