Authentication Issues with 3rd Party Cookie Blocking

In a few of our recent SharePoint/Azure projects we started seeing issues with cross-platform authentication in Safari browsers. After troubleshooting we found that it was due to 3^rd party cookie blocking. Here’s what we learned and how we solved the problem.

In March of 2020, Apple’s Safari browser enabled 3^rd party cookie blocking by default for both Macintosh and iOS platforms. This change has caused some technology challenges for our clients which we will discuss below.

Note that other browsers also offer 3^rd party cookie blocking, but they are mostly disabled by default. Google has announced that Chrome will have the option set by default by 2022.

What are 3^rd Party Cookies?

When browsing the web, 3^rd party cookies are created by domains other than the one currently being visited. Blocking them helps stop cross-site tracking and ads. However, this also prevents other domains that you do want to set a cookie from doing so.

Side Effects

We first experienced problems with authentication when we were working with custom SharePoint web parts that needed to pull information from an Azure API. The users were logged in to SharePoint, but when using Safari, Azure was unable to set an authentication cookie. This stopped the calls from working.

We have also seen issues when using SharePoint’s Stream web part being able to retrieve content.

Workarounds

Safari blocking these cookies is not an issue; it is a security necessity, and as noted above, other browsers will be doing this in the near future. The correct solution will be for companies like Microsoft to offer alternative authentication methods that do not rely on 3^rd part cookies. However, in the meantime, we needed a way to get information from Azure without using Azure AD to authenticate.

We could have asked our users to turn the blocking off, but for our particular audiences, this was not a viable choice. Also, is asking users to lower their browser’s security really a solution?

The solution we landed on was a mix of sending users directly to Azure for content viewing and using shared secret tokens rotating on a frequent schedule to connect to the API. We reviewed these changes with our client’s corporate security team, and while it was agreed that this was not the most secure method, the risk was considered low and we were allowed to move forward.

For Stream, the solution was to not embed the videos directly into SharePoint. Instead, we are sending users directly to Stream’s site. This is still secure, but the user experience is not what the client desired.

Next Steps

We will be watching how Microsoft and other companies address browsers becoming more secure. As the industry changes, we will work with our clients to revisit solutions and bring them in line with security best practices and desired user experiences.

Have you experienced issues with 3^rd party cookie blocking? If so, how did you address it? We’d love to hear your ideas and solutions!