Enhanced Whatfix End-User SSO

Read the following article to learn about how the enhanced End-User Single Sign-on (SSO) works, its advantages, the steps involved, and best practices.

Overview

Whatfix enables your organization to deliver content to the right end users with End-User SSO. If you have deployed Whatfix content on your application, the end-user authentication feature prompts your end users to authenticate themselves with valid credentials using your organization’s SSO. After authentication, they can view Whatfix content.

Previously, users were authenticated on click or when interacting with each piece of Whatfix content. To learn more about the current end-user authentication behavior, see End-user authentication.

With enhanced end-user SSO, Whatfix verifies end-user authentication before loading any Whatfix content, providing a smoother and less frequent authentication experience

Note:

• End-User SSO is a Beta feature. To enable this feature, contact support@whatfix.com.

• You need to configure SSO for the Whatfix Dashboard.

• If you use a Browser extension method of delivery, you must whitelist the Whatfix domains for the extension to access and display the content.

• Lack of permissions for domains such as whatfix.com and region-specific domains such as eu.whatfix.com might result in authentication failures and frequent re-login attempts.

• Ensure that such domains or any other specific domains are added to the site access settings of the browser extension page. For more information, see Change site settings for an extension.

With enhanced End-User SSO, Whatfix enables you to:

• Protect your content by restricting access to authorized users only. Your organization’s content stays safe — visible only to end users who have SSO access.

• Identify end users accurately across applications and sessions, providing insights to identify adoption and engagement gaps, and drive improvements with minimal setup.

• Segment content using SSO attributes by department, region, role, or any other attribute — all without relying on Whatfix or your IT team. Your end users see exactly what they need.

How does the End-User SSO work?

When an end user lands on the host application, a network of calls occurs in the background. The following image illustrates the process that begins when the end user accesses the client application from a browser:

The following steps outline the process shown in the preceding process image when an end user requests Whatfix content in an application integrated with End-User SSO:

Step 1: End user Requests Whatfix Content

The end user accesses your application and requests Whatfix content. Their browser sends a request to the Whatfix Content Delivery Network (CDN).

Step 2: CDN Initiates Authentication Request

The CDN detects that End-User SSO is enabled and triggers an authentication flow. It redirects the end user’s browser to the Whatfix API Service to initiate a SAML request.

Step 3: API Service Redirects to Identity Provider

The Whatfix API Service generates a SAML request and redirects the end user’s browser to your organization’s Identity Provider (IdP) for authentication.

Step 4: User Authenticates with Identity Provider

The end user signs in with their organization’s SSO credentials and the IdP verifies the end user’s identity.

Step 5: Identity Provider Returns Authentication Response

Upon successful authentication, your IdP sends a SAML response back to the user’s browser, which then redirects the response to the Whatfix API Service.

Step 6: API Service Validates Authentication

The Whatfix API Service validates the SAML request, confirming the end user’s identity and extracting relevant user attributes (such as email, department, role, and more) if defined in the Whatfix dashboard.

Step 7: Security Context is Set

The API service sets a secure authentication cookie (valid for 45 days) in the end user’s browser, establishing a security context for future content access.

Step 8: Content is Delivered

The end user’s browser re-contacts the CDN, presenting the secure cookie. The CDN verifies the authentication and securely delivers the requested Whatfix content.

Best Practices

• Whitelist SSO authentication tabs from the host application: Ensure your IT team whitelists authentication tabs for the host application (for example, Salesforce or Workday) so that the SSO authentication window is not blocked by the browser.

• Use a consistent SSO configuration: Configure your host application and Whatfix to use the same SSO provider.

• Pass relevant SSO attributes to Whatfix. Share relevant user attributes from your SSO provider into Whatfix. This enables precise content targeting based on role, location, department, and more.

Implementation Considerations

• Cookie expiry: The authentication cookie is valid for 45 days — end users stay signed in without repeated login prompts. The end user who logs in is authenticated on Day 0. Whatfix authenticates the end user again only on Day 45.

• Data security: Authentication tokens are managed in accordance with enterprise-grade security practices.
  By default, email addresses serve as end-user identifiers and are encrypted at rest using industry-standard encryption protocols. If required, you can configure a non-PII attribute — such as Employee ID — as the primary identifier.
  Whatfix also supports key SSO security features, including SAML request signing and SAML response encryption, to ensure secure, standards-compliant authentication.