Browser Impacts to the SSO Experience
8 min read
Both Firefox and Safari have recently made changes to their browsers in an effort to better support user privacy and we expect other browsers to follow suit. Learn how these changes have impacted the SSO (Single Sign-On) experience for your users.
Table of Contents
When the term Single Sign-On (SSO) is used we tend to think of being automatically logged in to corporate applications using the account we logged into our computer with. These are federated authentication flows, most commonly using SAML.
SSO under Customer Identity & Access Management (CIAM) is defined as follows:
- A single user account which can be used for authentication across multiple digital properties
- Shared data which is accessible by any site in the group
- Shared configuration which can be overridden at the site level
- The user is seamlessly logged in as they navigate between websites
The primary focus for this article is the final point, as this is the functionality which has been affected.
The SAP Customer Data Cloud SSO solution is cookie based and uses the web SDK, and therefore only works in a browser (mobile SSO is not supported as standard).Historically, the solution worked on the premise that there was a third party domain (www.gigya.com) holding the session information between different domains where SSO was to occur. The user would be redirected through the www.gigya.com domain as part of the login process using accounts.setSSOToken. A redirection through the third party domain was deemed to be enough for that domain to be 'trusted' and therefore the relevant cookies could be set to support the SSO process.
What Browser Changes Were Made?
Both Safari and Firefox have introduced changes which have impacted the SSO experience. User privacy was at the heart of these changes but there were unintended knock on effects to all CIAM vendor's SSO solutions. After the changes, redirecting through a third party domain was no longer enough for that domain to be 'trusted' and the user would now have to perform some kind of interaction with a page on that domain, such as clicking a button or entering some text in a field. Of course, SAP customers would not want their users to have to interact with the www.gigya.com domain for SSO to work.
Safari have since released additional changes under the banner of Intelligent Tracking Prevention that have restricted potential solutions further by completely blocking 3rd party cookies.
What No Longer Works?
The only functionality that the browser changes have impacted is the ability for a user to be seamlessly logged on when they navigate between websites. In many cases this can actually be a confusing behavior to the user anyway, especially if they do not know that there is a relationship between the two domains they are accessing.
If you were to make no changes at all, the user would have to re-enter their credentials on the other sites in the group before being able to access (they are no longer automatically signed in without action). There is however still a single account with shared data and one password in the database behind these sites.
What is the Solution?
Centralized Login Page
The solution to circumvent the recent browser changes are centered around a centralized login page. This is a page where the user is redirected to in order to login and replaces www.gigya.com as the domain where the session information is held. We must first choose which domain the centralized login page should be hosted on.
Let's say we have an SSO group with two domains; a.test and b.test, and we want to use our single account to login to both. The first option we have is to use a completely separate domain such as c.test (highlighted in red) where the user will be redirected from either a.test or b.test to login. Once login is successful, the user will be redirected back to the site they started on.
The SSO experience is as follows:
- User clicks login whilst on a.test
- They are redirected to c.test where they login and create a session
- They are redirected back to a.test where they now have a session
- The user navigates to b.test and is automatically logged in (see note below for browsers with Intelligent
In browsers will Intelligent Tracking Prevention (e.g. Safari) the user is not automatically logged in when they navigate to b.test. They must click the login button manually and they will be redirected to c.test where it recognizes they have an active session, and redirects them back to b.test.
The second option is that we can choose one of the existing domains to be the central login domain, like in the below example, a.test is the central login domain (highlighted in red).
So if a user wants to login to b.test, they would be redirected to a.test to perform the login and then redirected back after successful login. If the user starts their journey on a.test, there is no need for a redirect, because they are already on the central login domain.
The choice of central login domain will largely depend on the individual requirements of the customer.
Custom API Domain Prefix
A custom API domain prefix allows you to route traffic which is destined for SAP Customer Data Cloud via your own domain which allows for cookies to be treated as 1st party instead of 3rd party.
Without a domain prefix, when you inspect network traffic on a site using SAP Customer Data Cloud, you'll see requests go to gigya.com:
When using the domain prefix login-us1, you see traffic is routed through my own domain gigya-cs.com (a domain setup for the services team to build demos on):
Whatever the domain prefix is set as is prepended to the shortest configured trusted domain that the site which is calling these Customer Data Cloud APIs is hosted on. So in the above example I have a test page located at http://login-us1.gigya-cs.com, which is a valid CNAME which points at Customer Data Cloud.(not a real page) and I've set my domain prefix to login-us1. The Customer Data Cloud SDK automatically routes traffic through prefix + top-level domain, which is
The custom API domain must relate to the centralized login page, so if we take the above example where c.test is the central login domain, the CNAME used for the domain prefix would be something like login.c.test or accounts.c.test. If a.com is the central login domain, the CNAME would be login.a.test or accounts.a.test. The value of the prefix itself doesn't matter as long as it resolves to a valid CNAME.
Once we have a central login page and custom API domain prefix configured, the final configuration is the storage domain override. Here we are telling Customer Data Cloud where we will store the cookies that are relevant for the SSO flow. In the above examples the storage domain override would be login.c.test/accounts.c.test or login.a.test/accounts.a.test, depending on where the centralized login domain is.
For more detailed instructions on the steps required to support SSO in safari, follow this guide.
Recent browser changes with a focus on user privacy have changed how we have to look at traditional Single Sign-On. We see that SSO has started to be more closely aligned to the user journey familiar with traditional federation methods like SAML or Open ID Connect.
We can only expect more browsers to follow suit at a time where user privacy is at the forefront of user expectations, and therefore, we should familiarize ourselves with the changes required to adopt this new approach.