user-lockSSO — End Customers

Configure SAML 2.0 SSO for end-customer login on Reach experiences.

Set up SAML-based SSO so customers sign in with your IdP.

Overview

Customer SSO lets end customers access Reach-powered experiences using brand-managed credentials. Reach supports SAML 2.0 and integrates with your Identity Provider (IdP).

Reach never stores passwords. Authentication always happens on your systems.

circle-info

This page covers end-customer SSO only. For agent SSO into Reach Central, use SSO — Agents.

Why brands enable customer SSO

  • Remove duplicate customer credentials.

  • Reduce login friction and password resets.

  • Keep MFA and security policy in your IdP.

  • Ensure a consistent identity across brand and Reach experiences.

Where it’s used

Customer SSO can be enabled for Reach-powered self-care and checkout experiences, including:

  • Reach-managed brand websites

  • Reach-managed mobile web

  • Reach-managed mobile apps

How authentication works (SP-initiated SAML 2.0)

Reach uses a Service Provider (SP)-initiated SAML flow.

1

Customer initiates login

Customer clicks Log in from a Reach-powered experience.

2

Redirect to your IdP

Reach redirects the customer to your IdP login page.

3

Authentication happens on your systems

Customer enters credentials in your IdP. Reach is not involved in credential validation.

4

IdP sends a signed SAML assertion to Reach

Your IdP sends a digitally signed SAML response to Reach.

5

Reach validates and establishes a session

Reach validates the signature and required attributes. Reach then creates a session for the customer.

Required identity attributes (customer assertion)

The SAML assertion must include the fields Reach uses to identify and link the customer. You define the exact attribute names during mapping.

Attribute
Required
What Reach uses it for

Username

Yes

Identifies the customer in the Reach session.

Email address

Yes

Communications and account matching.

Customer account ID

Yes

Your internal identifier used to link to the correct Reach account.

circle-exclamation

Sample SAML SSO Attribute Payload (Reach)

These examples show the attributes Reach expects after mapping.

Your IdP attribute names can differ. Reach maps them during setup.

Customer SSO – Additional parameters

Example (Customer login)

Session behavior

  • Reach establishes a session token after SAML validation.

  • Backend API calls during the session are validated against the token.

  • If the token expires or is invalid, the customer is redirected back to your IdP to re-authenticate.

Security model

Your brand remains the system of record for identity.

  • Your brand controls password policies, MFA requirements, lockouts, and access revocation.

  • Reach trusts only digitally signed SAML assertions.

  • Unsigned or tampered assertions are rejected.

  • Reach does not store or expose customer passwords.

Responsibilities

Your brand provides

  • IdP-side SAML configuration.

  • SSO login endpoint (IdP URL).

  • X.509 certificate for assertion signing.

  • Attribute mappings for customer assertions.

  • Customer identity lifecycle management.

  • MFA, lockouts, and access policy enforcement.

Reach provides

  • SP metadata for IdP configuration.

  • Assertion Consumer Service (ACS) endpoints.

  • Secure session handling post-authentication.

  • Support during setup and testing.

Commercial and onboarding considerations

SSO is a paid add-on. It must be contracted explicitly.

  • Selecting SSO adds build time during onboarding.

  • Enabling SSO post-launch typically requires a formal change order.

Setup checklist

1

Confirm IdP readiness

Confirm your IdP supports SAML 2.0 SP-initiated flows.

2

Exchange metadata

Reach provides SP metadata and ACS details. You provide IdP metadata and signing certificate details.

3

Map required attributes

Map Username, Email address, and Customer account ID.

4

Test login and logout behavior

Validate:

  • login redirect and return to the correct page

  • token expiry and re-authentication

  • expected behavior after logout / session invalidation

5

Sign off for production

Complete non-production testing before requesting production enablement.

circle-info

Questions or clarification? Reach out to your respective account manager or email at [email protected]

Last updated