Gigya's plugins rely on cookies set in the users' browsers. These cookies are recognized by browsers as "third-party cookies", which the browser may be configured to block. In some browsers, such as Safari, third-party cookies from unvisited sites are blocked by default. Incognito/private browsing mode has no effect on this behavior.
Blocked third-party cookies may prevent Gigya services from working properly:
- In all cases, the recommended best practice is to use a Custom API Domain Prefix. A Custom API Domain Prefix enables calls to Gigya to appear to be local by utilizing a cname alias directing all API calls to the Gigya servers. To implement this solution, contact Gigya Support via the support portal located within your Gigya Console's top menu, or click here to login.
In all cases, browsers that do not, at a minimum, have Accept Cookies From Sites I Visited enabled, are not supported.
It is important to note that a Custom API Domain Prefix will solve the SAML login only if the site is not part of an SSO group. However, if the site is part of an SSO group, the Custom API Domain Prefix will only solve SP-Initiated SAML login; IdP-Initiated SAML login does not work on any browser with this method.
By default, when the Gigya JS SDK is loaded in a webpage, if it sees the user is using a browser that blocks third-party cookies by default (e.g., Safari), it will attempt to set the required data in Local Storage to solve the problem.
Even with the two above-mentioned workarounds, Single Sign-On (SSO) may not function properly if the user has third-party cookies blocked. This is because SSO requires that users let their login session be shared between multiple domains. For SSO solutions, see Supporting SSO and SAML Login in Browsers That Block Third-Party Cookies, below.
Supporting SSO and SAML Login in Browsers That Block Third-Party Cookies
It is becoming increasingly common for certain browsers to block 3rd party cookies for non-visited sites by default, which can cause Single Sign-on and/or Federated login to fail if Gigya is not yet marked as 'visited' by the browser.
This can be solved by implementing the following workaround.
The implementation is simple and short, and consists of the following steps:
Step 1 - Enable SSO Token
Set the global conf object's enableSSOToken parameter to 'true'.
This tells the server to issue an SSO token that will allow the workaround in case of blocked 3rd party cookies.
You can set this in the head of your page as part of the gigya.js script's global Conf object:
Step 2 - Call setSSOToken()
After a successful login, register to the onLogin event and call gigya.setSSOToken().
This will initiate a redirect that will set an SSO token with Gigya for the logged-in user and enable transparent Single Sign-on for the current session.
You can supply a redirect URL for where the browser will be redirected to once the process is complete.
The URL must be within the same domain that performed the login and the page it refers to must contain the gigya.js script.
Step 3 - SSO on iOS
Once the previous 2 steps are implemented, Gigya will recognize that the user is running a system that requires this workaround, and will set the SSOToken that will provide transparent SSO, even on systems with blocked 3rd party cookies.
SSO Supported Browsers
For a detailed list of browsers currently supported using Gigya SSO/SAML, please see Supported Browsers.