Using Safari with the JavaScript SDK and Social Login

Important. The content on this page deals with single sign-on (SSO) using the JavaScript SDK. Due to changes in web browser technology, including the fact that most browsers prohibit the use of third-party cookies, SSO using the JavaScript SDK is no longer available to new Identity Cloud customers. (However, we will continue to support existing customers who use this methodology.) If single sign-on is important to you we recommend that you use Hosted Login for your login and registration needs. See our Getting Started Guide to learn more about how single sign-on is implemented in Hosted Login.

If you are using the JavaScript SDK (i.e., the “widget”) to power your Identity Cloud website, you might run into the following scenario any time users running the Safari web browser try to access your site by using social login:

  1. Users go the site and click one of your social login providers:



  2. A popup window appears, and the user successfully authenticates with the social login provider:



  3. After the social login is complete, the social login popup window disappears. However, the user is not logged on to your site nor is the user redirected; instead, they remain “stuck” on your sign-in page:

Why is this happening, and why is it only happening to users running the Safari browser? 

The answer to both of those questions has to do with Apple’s Intelligent Tracking Prevention (ITP) technology, a privacy-protection feature designed to block cookies and to prevent advertisers from tracking your journeys across the Internet. The ITP technology helps a user maintain a higher level of privacy; at the same time, however, ITP can create problems for Safari users trying to use social login to access a website. 

Fortunately, there’s an easy fix for this issue. If your users are encountering this problem, it’s likely because your website is running in “popup mode.” That simply means that, when a user logs on to your site, they aren’t redirected to the social login provider in order to authenticate. Instead, a popup window appears on top of your sign-in page, and the user authenticates by using the popup window. It’s the popup window that’s creating the problem.

Note. This also explains why you might be using the JavaScript SDK and not running into the Safari-related issue described here: if you aren’t using popup mode users will be able to sign in to the social login provider without any problem.

We should also note that these ITP enhancements were introduced in Safari 13.1. If users are running older versions of Safari they might not encounter problems with the popup window.

If the popup window is causing problems, the solution iws pretty straightforward: get rid of the popup window. To do that, open the janrain-init.js file and locate these two lines of code:

janrain.settings.capture.redirectFlow = false;
janrain.settings.popup = true;

Those lines enable the use of the popup window. To get rid of the popup window (and thus allow Safari users to use social login), change the two lines so they read like this (note the new setting values, shown in red):

janrain.settings.capture.redirectFlow = true;
janrain.settings.popup = false;

And what does that accomplish? Well, the next time a Safari user tries to log on to your site by using social login, the popup window won’t appear: instead, the user will be redirected to the social login provider’s site and will authenticate from there. Assuming authentication succeeds, the user will be logged on and then redirected back to your site (by which we mean the actual site and not the sign-page page).

Note. OK, with one exception: if the user is creating a new account, they’ll be redirected to the socialRegistration screen, where they must complete the new account process before they can be logged on.

Note, too that this is only an issue if you are using the JavaScript SDK; that’s because the SDK relies heavily on third-party cookies (especially when using popup mode), and ITP is designed to prevent the use of third-party cookies. This problem doesn’t crop up in Hosted Login, because Hosted Login doesn’t use third-party cookies for user authentication.