Limit SSO to customer logins

Customer SSO (Single Sign-On) directs the online store login from AI Commerce to the AWS Cognito authorization page and from there to the selected identity provider. After a successful return, AI Commerce validates the identifier and logs the customer into their local customer account. This customer journey should be separated from the Admin login in the Dashboard, although both can use Cognito.

SSO does not automatically replace email-password sign-in. Before you deploy, decide whether to display both methods, which customer groups will be allowed to use SSO, and how the user will revert to regular sign-in in the event of an identity provider outage. The text Or sign in using on the public sign-in page indicates an alternative sign-in method, but the buttons available depend on your store's Cognito configuration.

Select an identity provider and account association rule

The identity provider can be Google, Amazon, Facebook, Apple, or Microsoft Entra ID, but the name should not be interpreted as a promise of ready support. For each provider you deploy, confirm the Cognito connection, required protocol, client identifier, email assertion trustworthiness, login view name, and test environment.

Before activation, decide whether to connect the SSO login to an existing customer account or create a new account. The store customer view searches for a local customer by email, regardless of the identity provider, and uses the found account; if the account is not found, it creates a new SSO customer identifier by email, first name, and last name. Therefore, all service providers must be restricted to returning a unique, verified email before production use.

Do not activate a provider if it can return unverified, reused, forwarded, or user-altered email without a trustworthy verification indicator. Incorrect email trust can connect the sign-in to another customer's existing account. Provider-specific differences should be resolved in the Cognito configuration and application account-linking logic, not based on the marketing name.

Collect Cognito and application configurations

Customer SSO login requires a Cognito user pool, AWS region, Cognito domain, application client ID and secret, and the identity provider's own application registration. The public client secret is not placed in the browser or in a text field in the Control Panel, but in the server's approved secret manager.

Register a specific callback address for each store host in the format https://<store-host>/api/auth/callback . AI Commerce constructs the address from the request protocol and host, so the proxy must forward the correct HTTPS protocol and accepted host. Also add a logout return address to the store root. Test and production environments must have separate, pre-allowed addresses.

AI Commerce requests the OpenID Connect scopes openid email profile and uses the authorization code flow. In the callback, the token signature is verified with Cognito keys and issuer, audience, validity, token use, state, and nonce values. The identity provider must return at least an email; first and last name enhance the basic information for a new account but do not replace email verification.

Submit a support request for implementation

SSO deployment is initiated by opening the Dashboard's Support → Create support request . Select the closest topic and name the store and test and production hosts, desired identity provider, Cognito environment owner, callback and logout addresses, account merging rule, customer email verification policy, and approver in the request.

Do not send the client secret in the free text of the support request or as an attachment. Agree with support on an approved secret delivery channel. Also, tell them whether regular login will be maintained, whether a new SSO customer needs to be approved for a company role separately, how to fix the incorrect association, and where to check the login event logs.

The free nature of public identity providers or the price of an enterprise solution cannot be inferred from the technical implementation. Request a written scope, license, and project definition before approval if the implementation has a commercial impact.

Test login and account linking

SSO login is first tested with separate test customer accounts. Test new email, existing email, missing email, unconfirmed email, provider canceled login, invalid state or nonce, expired token, and incorrect callback host. Make sure that a failed attempt does not create a customer account or log the user in.

When testing an existing email, make sure that the correct local customer account opens and that a different identity provider's ID is not accessing the account based on the email string alone. When testing a new customer, check the customer ID, email, name, default address, sso:<provider> entry in the creation history, customer group, and all company role approval criteria.

Also test parallel email-password login, logout, and login using a different browser. The Cognito session is persisted in the customer session, and logout returns the Cognito logout details, so both the local and Cognito sessions must end. Only accept production when there is confirmation of login, correct account mapping, blocked error paths, and successful logout from each allowed provider.

Track production SSO logins

Production SSO logins should be tracked for successes, rejection reason, identity provider, new account creation, existing account merging, and logout without unnecessarily logging credentials or personal information. AI Commerce logs the login attempt and the source of the new SSO customer creation, but technical success alone does not prove that the email belonged to the right person.

Suspend the provider if you notice incorrect account allocation, missing email verification, unexpected host, callback errors, or an abnormal number of new accounts. Maintain the standard login path as agreed upon during deployment and treat account separation, merging, or deletion as a traceable customer data action.